| 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 |
|
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
