Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
E-P-S

Anmeldungsdatum: 16.09.2004 Beiträge: 500 Wohnort: Neuruppin
|
Verfasst am: 20.04.2010, 15:17 Titel: Mal wieder UDT und Pointer Problem. |
|
|
Es tut mir leid, aber irgendwie raff ich es einfach nicht so sehr ich mich auch bemühe.
Folgende Situation. Ich erstelle ein UDT
Code: | Type UDT
pGNode As Integer
fErase As Byte
End Type |
In einer Funktion speichere ich mir den Pointer auf ein erstelltes UDT bzw. füge den Pointer als lParam in eine TV_ITEM Struktur ein (TreeView Node):
Code: | tvis.item.lParam = VarPtr(myUDT) |
In einer anderen Funktion möchte ich beim Auslesen des Node gerne wieder auf das UDT zugreifen können:
Code: | Dim myUDT As UDT Ptr
Dim item As TV_ITEM
item.hItem = hNode
TreeView_GetItem( hTrV, @item )
myUDT = Cast( UDT Ptr, item.lParam )
Return myUDT->pGNode |
nur leider klappt das nicht.
Was mache ich falsch? _________________ Man kann sich öfter als zweimal im Leben halb tot lachen. |
|
Nach oben |
|
 |
ThePuppetMaster

Anmeldungsdatum: 18.02.2007 Beiträge: 1839 Wohnort: [JN58JR]
|
Verfasst am: 20.04.2010, 15:45 Titel: |
|
|
versuche mal:
Code: |
'### UDT definieren
Type UDT
pGNode As Integer
fErase As Byte
End Type
'### UDT speicherplatz erzeugen
Dim tempUDT as UDT Ptr = CAllocate(SizeOf(UDT))
'### bissi stuff rein pumpen
tempUDT->pGNode = 2345
tempUDT->pGNode = 1
'### vermutlich >POINTER< vom UDT iins tree kopieren.
'### VarPtr auf ein bereits Ptr'te Variable gibt dir nicht den Pointer auf den speicher des UDT's, sondern auf den speicher der variable, in welchem der pointer auf den UDT-SPeicher liegt, zurück.
tvis.item.lParam = tempUDT
'### neue UDT Variable erzeugen
Dim myUDT As UDT Ptr
Dim item As TV_ITEM
'### vermutlich pointer auf UDT wieder hohlen
item.hItem = hNode
TreeView_GetItem( hTrV, @item )
'### und zur variable casten
myUDT = Cast( UDT Ptr, item.lParam )
'### wret ausgeben
Return myUDT->pGNode
|
wenn du das oben angegebene VarPtr nutzt, dann musst du einen weiteren point-cast machen. Aber das is komplizierter als es zu nutzen.
Das sollte bei deinem beispiel funzen (ungetestet)
Code: |
Return (*Cast(UDT Ptr, MyUDT))->pGNode
|
Dabei wandelst du den zurückgeholten Pointer in einen UDT Ptr Pointer um (quasi das invers zum VarPtr) und anschliessend greifst du auf den Speicher der Variable zu, welcher nun als Pointer Cast zum eigentlichen UDT Ptr zeigt. Dann kannst du auf den Wert zugreifen.
MfG
TPM
Return _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
 |
E-P-S

Anmeldungsdatum: 16.09.2004 Beiträge: 500 Wohnort: Neuruppin
|
Verfasst am: 20.04.2010, 15:54 Titel: |
|
|
Oh Mann,
das CALLOCATE(SIZEOF(UDT)) ....
ist ja logisch, ich muß ja für jedes anglelegt UDT erstmal Speicher anlegen
ok, das hab ich damit zum Laufen bekommen - heftigsten Dank.
Eine Frage noch:
Da ja nun Speicher reserviert wird, jedesmal wenn ich einen solchen UDT mit meinem TreeView verknüpfe, sollte man den sicherlich wieder freigeben.
Passiert dies automatisch wenn ich den Eintrag aus dem TreeView lösche, da so auch der Handle auf's UDT verloren geht? Oder muß ich das vorher (wenn ja wie) explizit wieder freigeben? _________________ Man kann sich öfter als zweimal im Leben halb tot lachen. |
|
Nach oben |
|
 |
St_W

Anmeldungsdatum: 22.07.2007 Beiträge: 956 Wohnort: Austria
|
Verfasst am: 20.04.2010, 16:09 Titel: |
|
|
Soweit ich weiß musst du das in FB selbst wieder freigeben.
Höhere Programmiersprachen würden sowas automatisch machen (z.B. C#). _________________ Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
Nach oben |
|
 |
Jojo alter Rang

Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 20.04.2010, 16:10 Titel: |
|
|
Zitat: |
Passiert dies automatisch wenn ich den Eintrag aus dem TreeView lösche, da so auch der Handle auf's UDT verloren geht? |
Das wäre Garbage Collection à la Java, was es in FreeBASIC nicht gibt (ist auch besser so). Ob man bei Callocate auch wieder deallocate ausführen muss, weiß ich nicht; wenn du allocate (statt Callocate) verwendest, solltest du das aber definitiv tun.
St_W hat Folgendes geschrieben: | Höhere Programmiersprachen würden sowas automatisch machen (z.B. C#). |
Dir ist die definition von "höhere Programmiersprache" bekannt? Nach keiner mir bekannten Defintion ist C# eine "höhere" Programmiersprache als FreeBASIC! _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
Nach oben |
|
 |
E-P-S

Anmeldungsdatum: 16.09.2004 Beiträge: 500 Wohnort: Neuruppin
|
Verfasst am: 20.04.2010, 16:24 Titel: |
|
|
Ok, vielen Dank nochmals an euch.
Nebenbei: Das Anlegen geht auch mit NEW und das Deallocieren logischerweise auch mit Delete. Man muß also nicht CAllocate oder Allocate nehmen.
Dies nur für andere die mal über den Thread hier stolpern  _________________ Man kann sich öfter als zweimal im Leben halb tot lachen. |
|
Nach oben |
|
 |
ThePuppetMaster

Anmeldungsdatum: 18.02.2007 Beiträge: 1839 Wohnort: [JN58JR]
|
Verfasst am: 20.04.2010, 16:27 Titel: |
|
|
(C)Allocate >sollte< immer DeAllocate'ed werden. Unter Linux wird das zwar rabiat gehandhabt, udn der speicher nach programmende automatisch mit getilt, aber ob das utner win auch so is, kann ich nciht mit sicherheit sagen. Zumidnest sind die anzeichen daführ früher eher schelcht gestanden.
Das C vor dem Allocate sagt ja nur aus, das der Speicher nach der reservierung mit 0 aufgefüllt wird, um (vorallem bei Poitner in UDT's zu empfehlen) zu verhindern, das Daten in der Variablen stehen, die man dort nie rein geschrieben hat. Bei LinkedList's is das vorallem sehr sinnig, um zu verhindern, das auf einmal Pointer vorhanden sind, die zuvor nie erzeugt wurden, bzw. Werte, die als Pointer von FB, bzw. dem MM interpretiert werden.
MfG
TPM _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
 |
Jojo alter Rang

Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 20.04.2010, 16:35 Titel: |
|
|
ThePuppetMaster hat Folgendes geschrieben: | (C)Allocate >sollte< immer DeAllocate'ed werden. Unter Linux wird das zwar rabiat gehandhabt, udn der speicher nach programmende automatisch mit getilt, aber ob das utner win auch so is, kann ich nciht mit sicherheit sagen. Zumidnest sind die anzeichen daführ früher eher schelcht gestanden. |
Nach Programmende ist auch unter Win "alles weg". _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
Nach oben |
|
 |
Sebastian Administrator

Anmeldungsdatum: 10.09.2004 Beiträge: 5969 Wohnort: Deutschland
|
Verfasst am: 20.04.2010, 16:56 Titel: |
|
|
[OT]
Zitat: | Nach Programmende ist auch unter Win "alles weg". |
Ja, um aber Memory Leaks zu verhindern, sollte man nicht nur darauf bauen, dass nach der Programmbeendigung alles weg ist, sondern bereits während der Programmlaufzeit darauf achten, dass dynamisch bereitgestellter Speicher auch wieder freigegeben wird. Wenn eine Anwendung lange läuft (z.B. ein Serverdienst), soll sie ja nicht im Laufe der Zeit den gesamten Arbeitsspeicher in Beschlag nehmen, bis nichts mehr geht.
[/OT] _________________
Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen! |
|
Nach oben |
|
 |
ThePuppetMaster

Anmeldungsdatum: 18.02.2007 Beiträge: 1839 Wohnort: [JN58JR]
|
Verfasst am: 20.04.2010, 17:26 Titel: |
|
|
Jojo hat Folgendes geschrieben: | Nach Programmende ist auch unter Win "alles weg". | Da geb ich dir recht .... >ALLES< weg
MfG
TPM _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
 |
MisterD

Anmeldungsdatum: 10.09.2004 Beiträge: 3071 Wohnort: bei Darmstadt
|
Verfasst am: 20.04.2010, 17:33 Titel: |
|
|
auch die erwähnten "höheren" programmiersprachen würden von hand allozierten speicher nicht freigeben. Faustregel: Was man von hand reserviert muss man von hand wieder freigeben. Die höheren programmiersprachen haben einfach in der Regel keinen mechanismus mehr, von hand speicher zu allozieren. Das ist ja auch einfach nur unschön zu benutzen  _________________ "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra |
|
Nach oben |
|
 |
Jojo alter Rang

Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 20.04.2010, 20:23 Titel: |
|
|
Sebastian hat Folgendes geschrieben: | [OT]
Ja, um aber Memory Leaks zu verhindern, sollte man nicht nur darauf bauen, dass nach der Programmbeendigung alles weg ist, sondern bereits während der Programmlaufzeit darauf achten, dass dynamisch bereitgestellter Speicher auch wieder freigegeben wird. Wenn eine Anwendung lange läuft (z.B. ein Serverdienst), soll sie ja nicht im Laufe der Zeit den gesamten Arbeitsspeicher in Beschlag nehmen, bis nichts mehr geht.
[/OT] | Ich hab auch nie behauptet, dass das eine gute Technik wäre oder dass ich das so machen würde. TPM hat ja nur gemeint, dass das unter Linux funktioniert. Ich meinerseits gebe Speicher grundsätzlich so früh wie möglich wieder frei.  _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
Nach oben |
|
 |
St_W

Anmeldungsdatum: 22.07.2007 Beiträge: 956 Wohnort: Austria
|
Verfasst am: 20.04.2010, 20:32 Titel: |
|
|
Mit "höher" meinte ich eigentlich so ca. "weiter von der Hardware entfernt". Und FB (was ich gerne mit C gleichsetzte) ist da für mich weiter "unten" als etwa C# / Java (ist ja auch wieder ziemlich ähnlich).
Und C# gibt definitiv Speicher, den man z.B. beim Anlegen einer Variable angefordert hat (z.B. "myClass test = new myClass();"), mit dem integrierten Garbage Collector wieder frei, wenn keine Referenz darauf mehr existiert.
Aber egal. In FB sollte man jedenfalls den Speicher wieder freigeben - obwohl der Speicher von Windows später sowieso freigegeben wird. _________________ Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
Nach oben |
|
 |
MisterD

Anmeldungsdatum: 10.09.2004 Beiträge: 3071 Wohnort: bei Darmstadt
|
Verfasst am: 20.04.2010, 21:51 Titel: |
|
|
ein objekt instanzieren hatte ich jetzt nicht als manuell speicher allozieren angesehen ;P normal angelegte variablen werden ja grundsätzlich von alleine wieder freigegeben _________________ "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra |
|
Nach oben |
|
 |
|