[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

code:

---

SUB NewList(BYVAL list&)
	POKEL list& + lh_Head%, list& + lh_Tail%
	POKEL list& + lh_Tail%, 0
	POKEL list& + lh_TailPred%, list& + lh_Head%
END SUB

SUB AddName(Nodes&(),listh&,TmpVar$(0), BYVAL Anzahl%, Nodes%)
 LOCAL namenode&
	namenode&=AllocMem&(node_sizeof%,MEMF_CLEAR&)
	IF namenode&=0 THEN ERROR 7	' out of memory
        Nodes&(Anzahl%-Nodes%)=namenode&:INCR Nodes%
	POKEL namenode&+ln_Name%, SADD(TmpVar$(0))
	AddHead listh&,namenode&
END SUB

rem Aufrufsprinzip des Subs
AddName Nodes&(), listviewlist&, TmpVar$(), Einträge%, Nodes%


SUB FreeListGadget(BYVAL listhead&)
STATIC worknode&,nextnode&
worknode&=PEEKL(ListHead&+lh_head%)
DO
	nextnode&=PEEKL(worknode&+ln_Succ%)
	IF nextnode&=0 THEN EXIT LOOP
	FreeMem worknode&,node_sizeof%
	worknode&=nextnode&
LOOP
END SUB

 TAGLIST VARPTR(temptag&(0)), _
  WA_Title&,     "         Ein Fehler ist Aufgetreten", _
  WA_AutoAdjust&,  TRUE&, _
  WA_InnerWidth&,  455&, _
  WA_InnerHeight&, 102&, _
  WA_DragBar&,    TRUE&,      WA_DepthGadget&,   TRUE&, _
  WA_Activate&,   TRUE&,      WA_CloseGadget&,   TRUE&, _
  WA_SizeGadget&, FALSE&,     WA_SmartRefresh&,  TRUE&, _
  WA_IDCMP&, IDCMP_CLOSEWINDOW&+IDCMP_REFRESHWINDOW&+ _
  +IDCMP_MOUSEBUTTONS&, _
  WA_PubScreen&, mysc&, _
 TAG_END&

 mywinFR& = OpenWindowTagList&(NULL&,VARPTR(temptag&(0)))

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

code:

---

POKEL namenode&+ln_Name%, SADD(TmpVar$(0))

AddName Nodes&(), listviewlist&, TmpVar$(), Einträge%, Nodes%

---

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

listhead&=AllocMem&(list_sizeof,MEMF_CLEAR&)
NewList listhead&
FOR i=15 TO 0 STEP -1
	AddName	listhead&,"line"+STR$(i)
NEXT i

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Also brauche ich ein Array welches dableibt bis das Listview
weg ist richtig?

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>Deine Namen kommen offenbar aus TmpVar$. Aber was das ist, wo es herkommt und wie lange es lebt, darüber schreibst du gar nichts.

Ja, ich hab ebend noch experimentiert.
Die größe eines Nodes ist 20 Bytes, darin passt ja nun nie und nimmer
ein String mit einer länge von ca. 25 Zeichen und dazu noch die
Zeiger.

---

Zitat:

---

Das MaxonBasic Beispiel war ja:

code:

---

listhead&=AllocMem&(list_sizeof,MEMF_CLEAR&)
NewList listhead&
FOR i=15 TO 0 STEP -1
	AddName	listhead&,"line"+STR$(i)
NEXT i

---

also ein Temporärer String, ich ging davon aus das dieser nach
dem 1. mal weg ist und von daher dachte ich nicht das ich diesen
erhalten müsste.

---

Zitat:

---

Das Beispiel konnte ich auch sofort abstürzen lassen indem ich nach diesem
Code noch diverse Strings erstellte/veränderte und danach
CreateGadgetA& aufgerufen habe.

---

Zitat:

---

Bei meinem Programm wird ja mit 100x soviel einträgen gearbeitet.
Das erhöhen des Heaps erhöhte also nur den Puffer für Temporäre,
Strings die viel länger dableiben als ich dachte.

---

Zitat:

---

Also brauche ich ein Array welches dableibt bis das Listview
weg ist richtig?

---

Genau. Woher soll sich das ListView sonst die Daten holen, wenn z.B. ein Refresh angesagt ist? Die temporären Daten sind ja u.U. schon längst wieder futsch.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Also brauche ich ein Array welches dableibt bis das Listview
weg ist richtig?

---

code:

---

SUB AddName(Nodes&(),listh&,Name$, BYVAL Anzahl%, Nodes%)
  LOCAL namenode&
  namenode&=AllocVec&(node_sizeof% + LEN(Name$)+1,MEMF_CLEAR&)
  IF namenode&=0 THEN ERROR 7	' out of memory
  Nodes&(Anzahl%-Nodes%)=namenode&:INCR Nodes%
  POKE$ namenode&+node_sizeof%, Name$
  POKEL namenode&+ln_Name%, namenode&+node_sizeof%
  AddHead listh&,namenode&
END SUB

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

AddName	listhead&,"line"+STR$(i)

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Schau mal in RKM was AddName genau will

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>Für sowas legst du besser globale Variablen an, oder wenn schon lokal,
>dann stelle zumindest sicher dass ihre Lebensdauer länger ist als
>das Listview bzw. Fenster exisitiert.
>Das hat auch nichts mit Garbadge Collection zu tun, hat MBasic sowas überhaupt ?
>Alles andere ist super Pfusch und crashed früher oder später.

Es spielt keine Rolle ob ein String Lokal, Static oder Global ist
MaxonBasic ändert ALLE Pointer von Strings bei einer Garbage Collection.

---

Ich kann mich ganz dunkel daran erinnern, daß man MB mitteilen konnte, in welcher Form die GC abgewickelt wird.

Normal werden bei der GC auch die Strings "neu sortiert", soll heißen, die Fragmentierung des Heaps wird beseitigt. Das scheint bei Dir der Fall zu sein.

Soweit ich mich erinnere, konnte man MB aber von der Defragmentierung des String-Speichers abhalten, aber frag mich nicht, welche Option dafür zuständig ist. Blick ins Handbuch dazu könnte helfen.

Andererseits ist Holgers Lösung geradezu brilliant, um weitere mögliche Probleme mit der GC zu verhindern.

Mach das besser so, wie Holger vorgeschlagen hat, dann gibts keine Sorgen in der Hinsicht.

Und für das nächste Mal weißt Du dann, wie man solche Problemchen umgehen kann

Zitat:

---

Ich könnte natürlich einen 4 Stelligen String in eine Long Integer
geben aber für einen 40 Stelligen String ist das noch umständlicher
als AllocMem.

---

Es ist noch die Frage, ob Dir das wirklich weiterhelfen würde. Mit ein bißchen Pech betreibt MB Wiederverwendung mit dem Platz der jeweiligen LONGs, dann geht das Theater von vorn los.

Das Schlaueste ist es wohl wirklich, das Ganze in C-Manier zu handhaben, also die Strings via AllocVec() von Hand zu allozieren und an die Node-Struktur anzuhängen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Der_Wanderer:
Das hat auch nichts mit Garbadge Collection zu tun, hat MBasic sowas überhaupt ?

---

Ja, hat es. Das hat jeder echte BASIC-Interpreter/Compiler.

AmiBlitz fällt da aus der Reihe, im Prinzip ist es kein echter BASIC-Compiler sondern eine Mischung aus C-Compiler und BASIC-Schlüsselworten und -Konstrukten. Kann sogar gut sein, daß AB auch eine Art Garbage Collector einsetzt, so weit habe ich den Compiler nicht durchblickt.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

code:

---

TAGLIST tagsl&,_
 WA_IDCMP&,IDCMP_CLOSEWINDOW&,_
 WA_Flags&,WFLG_CLOSEGADGET&+_
           WFLG_ACTIVATE&+_
           WFLG_SIZEGADGET&+_
           WFLG_DEPTHGADGET&+_
           WFLG_DRAGBAR&+_
           WFLG_SIMPLE_REFRESH&,_
 WA_MinHeight&,50,_
 WA_MinWidth&,100,_
 WA_Title&,"Netzwerkfenster",_
 TAG_END&
 con_win&=OpenWindowTagList&(0,tagsl&)

---

code:

---

REM Die folgende Funktion brauch ich nur, weil sonst MaxonBasic mir die
REM Namen in den Fenstern versaut, wenn er wiedermal einfach die variablen
REM aufräumt
FUNCTION AllocName&(c$,BYVAL n)STATIC
 SHARED AllocN&()
 IF AllocN&(n)THEN FreeMem AllocN&(n),PEEKW(AllocN&(n)):AllocN&(n)=0
 a$=c$+CHR$(0)
 a&=LEN(a$)+2
 b&=AllocMem&(a&,MEMF_PUBLIC&)
 IF b& THEN
  AllocN&(n)=b&
  POKEW b&,a&
  CopyMem SADD(a$),b&+2,LEN(a$)
 END IF
 AllocName&=b&+2
END FUNCTION

---

code:

---

...
 WA_Title&,AllocName&("Netzwerkfenster",0),_
...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>Soweit ich mich erinnere, konnte man MB aber von der
>Defragmentierung des String-Speichers abhalten, aber frag mich
>nicht, welche Option dafür zuständig ist. Blick ins Handbuch dazu
>könnte helfen.

Ich hab schon Handbuch und Docs abgesucht, es gibt zwar einen
Heap der nicht Dynamisch ist, da passiert aber das selbe.

---

Ok, dann wissen wir schon mal, daß man die GC in MB nicht weiter steuern kann. Der nicht-dynamische Heap macht übrigens die Garbage Collection gerade notwendig

Zitat:

---

>Andererseits ist Holgers Lösung geradezu brilliant, um weitere
>mögliche Probleme mit der GC zu verhindern.

Ja, hab das bereits Integriert, Funktioniert.
Obwohl ich mir nicht ganz sicher bin ob

POKEL namenode&+ln_Name%, namenode&+node_sizeof%

nicht

POKEL namenode&+ln_Name%, namenode&+node_sizeof%+1

heissen müsste.

---

Zitat:

---

>Das Schlaueste ist es wohl wirklich, das Ganze in C-Manier zu
>handhaben, also die Strings via AllocVec() von Hand zu allozieren
>und an die Node-Struktur anzuhängen.

Ja, das mit dem Listview ist ja nicht das schlimmste sowas muss ich
jetzt bei jedem Fenster machen...

---

Zitat:

---

Aber in C haben doch Strings eine feste länge und müssten deshalb
doch gar nicht "defragmentiert" werden oder?

---

Die Strings selbst nicht, nein. Aber stell Dir doch mal vor, was mit dem Hauptspeicher passiert, wenn Du den bis zum Bersten mit Strings vollstopfst und dann einige Strings veränderst, z.B. in der Größe oder halt das ein String gar nicht mehr benötigt wird, dann noch ein Neuer dazu, der den verfügbaren Hauptspeicher überschreiten würde, sofern sich kein überflüssiger String in dem großen Haufen finden würde etc.

Dann hast Du das Gleiche, was in BASIC im relativ kleinen Variablen-Bereich passiert: Fragmentierung, die nach "Aufräumen" schreit.

Das Kuddelmuddel aufzuräumen ist in C dann aber wesentlich aufwändiger, weil der Compiler die tatsächliche Größe des Strings gar nicht kennt.

Er führt kein Buch darüber, was ein BASIC-Interpreter/Compiler hingegen tut.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Aber in C haben doch Strings eine feste länge und müssten deshalb
doch gar nicht "defragmentiert" werden oder?

---

Zitat:

---

Original von Ralf27:
Deswegen hatte ich mal ne Funktion für Strings geschrieben, die unabhängig von MB gehaltet werden müssen:

code:

---

REM Die folgende Funktion brauch ich nur, weil sonst MaxonBasic mir die
REM Namen in den Fenstern versaut, wenn er wiedermal einfach die variablen
REM aufräumt
FUNCTION AllocName&(c$,BYVAL n)STATIC
 SHARED AllocN&()
 IF AllocN&(n)THEN FreeMem AllocN&(n),PEEKW(AllocN&(n)):AllocN&(n)=0
 a$=c$+CHR$(0)
 a&=LEN(a$)+2
 b&=AllocMem&(a&,MEMF_PUBLIC&)
 IF b& THEN
  AllocN&(n)=b&
  POKEW b&,a&
  CopyMem SADD(a$),b&+2,LEN(a$)
 END IF
 AllocName&=b&+2
END FUNCTION

---

---

code:

---

REM Die folgende Funktion brauch ich nur, weil sonst MaxonBasic mir die
REM Namen in den Fenstern versaut, wenn er wiedermal einfach die variablen
REM aufräumt
REM Sie gibt 0 im Fehlerfall zurück
FUNCTION AllocName&(c$,BYVAL n)STATIC
  SHARED AllocN&()
  IF AllocN&(n) THEN FreeVec AllocN&(n)
  b&=AllocVec&(LEN(c$)+1, MEMF_PUBLIC&)
  AllocN&(n)=b&
  IF b& THEN
    CopyMem SADD(c$), b&, LEN(c$)
    POKE b&+LEN(c$), 0
  END IF
  AllocName&=b&
END FUNCTION

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Der nicht-dynamische Heap macht übrigens die Garbage Collection gerade notwendig

---

Zitat:

---

Im Prinzip machst Du damit aus der statischen String-Verwaltung von BASIC eine mehr oder weniger dynamische auf OS-Basis alá C. Allozieren von Speicher für einen String, so wie es in C der Compiler für einen erledigt.

---

Zitat:

---

Das Kuddelmuddel aufzuräumen ist in C dann aber wesentlich aufwändiger, weil der Compiler die tatsächliche Größe des Strings gar nicht kennt.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
>Die Strings selbst nicht, nein. Aber stell Dir doch mal vor, was mit
>dem Hauptspeicher passiert, wenn Du den bis zum Bersten mit Strings
>vollstopfst und dann einige Strings veränderst, z.B. in der Größe
>oder halt das ein String gar nicht mehr benötigt wird, dann noch
>ein Neuer dazu, der den verfügbaren Hauptspeicher überschreiten
>würde, sofern sich kein überflüssiger String in dem großen Haufen
>finden würde etc.

Naja gut meine Strings$ sind ja eine Sache aber MBasic behandelt
ja alles was in " " steht schon als String. Das ist ja nur zu
übergabe und kann sofort wieder weg. Da es aber nicht so ist muss
es ja zwangsweise zum Heap-voll kommen

---

Nicht nur MBasic behandelt alles in "" als String. Überleg doch mal, wie ein C-Compiler wohl vorgehen würde, wenn Du eine String-Konstante definierst. Auf diese darf ja per definitionem lesend zugegriffen werden, nur nicht schreibend und zum Zeitpunkt ihrer Deklaration ist die weitere Verwendung gar nicht bekannt.

Was macht ein C-Compiler damit wohl? Er schiebt sie vorläufig auf den Heap, so wie es ein BASIC-Compilerer auch macht. Ein BASIC-Compiler weiß, daß er die Konstante ggf. nur ein Mal verwendet, weswegen die GC auch nicht wegen der String-Konstanten auftritt bei diesem (beim Interpreter schon).

Wegen temporärer Strings tritt die GC aber auf, was z.B. gern bei String-Additionen wie z.B. String-Konstante + STR$ passiert.

Der Unterschied zu C besteht in der Behandlung "dynamischer" Strings, von denen C so gut wie gar keine Ahnung hat. Strings im BASIC-Sinn gibt es in C gar nicht! Weder statisch noch dynamisch. Da gibt es nur Arrays von char, die einen Start besitzen, aber kein bekanntes Ende.

Ohne die C-Standardbibliothek müßte sich ein C-Programmierer auch jedes Mal eine Bombe bauen, um mit Strings und deren Folgen umzugehen

Zitat:

---

>In C gibt es keine solchen Funktionen zum Bearbeiten von Strings
>ala "xyz"+abc$ oder MID$(abc$, x, y). Deshalb gibt es keinen
>Speichermanager. Das heißt aber noch lange nicht, dass es in C
>keine Speicherfragmentierung geben könnte.

Ja, Mid$ und so vermisse ich auch bei C...

---

Zitat:

---

Okay, hab jetzt alles im Programm angepasst.
Danke @All

---

Das und das es funktioniert ist die Hauptsache. Du kommst aber auch immer mit Sachen um die Ecke...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von MaikG:
Wie lange hast du gebraucht um herrauszufinden woran das liegt?
Ich meine kein Hinweis in den Beispielen oder im Handbuch.
Ich hab dann immer den Heap erhöht, mit der annahme das Programm
sei zu komplex. Es ging dann auch immer weil man normalerweise
ja nicht mit tausenden Strings handtiert.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Was macht ein C-Compiler damit wohl? Er schiebt sie vorläufig auf den Heap, so wie es ein BASIC-Compilerer auch macht.

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Was macht ein C-Compiler damit wohl? Er schiebt sie vorläufig auf den Heap, so wie es ein BASIC-Compilerer auch macht.

---

Eigentlich belässt er sie in der Daten-Sektion des Programms. Es sei denn, Du benutzt sie, um ein lokales char-array damit zu initialisieren, dann werden die Daten auf den Stack kopiert.

---

Zitat:

---

Aber bei bei Strings ala char* foo="bar"; werden überhaupt keine Daten kopiert oder verschoben, weswegen man den String eigentlich als const deklarieren müsste, was gerade ältere Compiler gerne ignorieren, neuere aber anmeckern, wenn man die entspr. Warning eingeschaltet lässt.

---

Mal abgesehen davon, daß ich so etwas kaum mache (gerade, wenn man viel mit OS-Funktionen hantiert, werden String-Konstanten reichlich lästig), der Hinweis ist wertvoll

Zitat:

---

Auf den Heap kopieren muss dagegen der Programmierer immer selbst, weil es die entsprechende Konstruktion ala new char[], die das automatisch machen könnte, in der Programmiersprache C nicht gibt.

---

Naja, es gibt sicher Linkerbibliotheken (abseits der Standardbibliothek), die diese Aufgabe übernehmen würden, sofern man diese Bibliotheken einsetzt.

Wie ich oben schon sagte, habe ich den Ausdruck Heap mit Rücksicht auf Maik eingesetzt.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]