DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
umm, hij word geïnitialiseerd bij de constructie, en weer vernietigd tijdens de destructie van LListquote:Op donderdag 17 maart 2011 18:33 schreef GS42 het volgende:
[..]
Dat is inderdaad een probleem, maar zijn fout wordt veroorzaakt door iets anders: bekijk je LList constructor LList(Piece start):_START(&start) eens goed. Wat klopt hier niet? (Hint: waar wordt 'Piece start' geinitialiseerd en wanneer wordt deze vernietigd?)
Ik neem aan de de _START pas vernietigd word nadat de rest van de destructor is uitgevoerd...
ja, dat dacht ik dus ook al maar als ik gewoon in de main dit schrijf:quote:Op donderdag 17 maart 2011 18:10 schreef thabit het volgende:
Je lijkt dingen te deleten die niet met new worden aangemaakt. Dat kan natuurlijk niet goed gaan.
| 1 2 3 4 | Pice myPiece; Piece *ptr; ptr = &myPiece; delete ptr; |
Beware of the Raping Zebra's
Je past daar pass-by-value toe. Dat ding wordt dus meteen al vernietigd bij het verlaten van de constructor.quote:
[..]
umm, hij word geïnitialiseerd bij de constructie, en weer vernietigd tijdens de destructie van LList
ow lol Xd, dat verklaard een hoop 
ik heb ze nu idd maar weer via new gemaakt en heb de error nu ook niet meer 
ow kut die Piece start word natuurlijk weer vernietigd... lekker dom weer
ik was al bang dat mn length() functie een fout bevatte die ik niet snapte
bedankt in ieder geval
ik heb ze nu idd maar weer via new gemaakt en heb de error nu ook niet meer ow kut die Piece start word natuurlijk weer vernietigd... lekker dom weer
ik was al bang dat mn length() functie een fout bevatte die ik niet snapte
bedankt in ieder geval
Beware of the Raping Zebra's
Hey heeft iemand een idee waarom dit niet werkt??
als bool b_temp = true; dan zou dit toch een oneindige loop moeten vormen die steeds read op ifstr_loc zet en dan iets gaat doen??
ik krijg nu dat Handle_Function 1x word uitgevoerd en daarna is read.tellg() -1 nadat seekg(44) is aangeroepen, kan iemand mij misschien vertellen waarom read.tellg() -1 word?
| 1 2 3 4 5 6 | int ifstr_loc = read.tellg(); while(b_temp){ read.seekg(ifstr_loc); std::cout << read.tellg( << '\n'; Handle_Function(read); } |
als bool b_temp = true; dan zou dit toch een oneindige loop moeten vormen die steeds read op ifstr_loc zet en dan iets gaat doen??
ik krijg nu dat Handle_Function 1x word uitgevoerd en daarna is read.tellg() -1 nadat seekg(44) is aangeroepen, kan iemand mij misschien vertellen waarom read.tellg() -1 word?
Beware of the Raping Zebra's
Ja, tenzij b_temp in Handle_Function aangepast wordt. Dan hoeft de loop niet oneindig te zijn.quote:
Hey heeft iemand een idee waarom dit niet werkt??
[ code verwijderd ]
als bool b_temp = true; dan zou dit toch een oneindige loop moeten vormen die steeds read op ifstr_loc zet en dan iets gaat doen??
Aannemende dat 'read' een of andere istream is, dan geeft tellg() -1 terug als deze faalt. Dit betekent hoogstwaarschijnlijk dat 'read' geen vailde status meer heeft, dus dat een of andere operatie in Handle_Function gefaald is. In het algemeen lees je nooit van een istream zonder te controleren of de istream wel leesklaar is. Probeer maar eens de statusbits van de istream af te drukken (eof, fail en bad), dan zal je zien dat dat de stream zich in een foutstaat bevindt.quote:ik krijg nu dat Handle_Function 1x word uitgevoerd en daarna is read.tellg() -1 nadat seekg(44) is aangeroepen, kan iemand mij misschien vertellen waarom read.tellg() -1 word?
[ Bericht 1% gewijzigd door GS42 op 03-04-2011 15:15:35 ]
"Slechts diegene mag slopen die iets beters kan bouwen."
Het klopt dat ik de check of ie valide is idd er niet in gedaan heb neequote:
[..]
Aannemende dat 'read' een of andere istream is, dan geeft tellg() -1 terug als deze faalt. Dit betekent hoogstwaarschijnlijk dat 'read' geen vailde status meer heeft, dus dat een of andere operatie in Handle_Function gefaald is. In het algemeen lees je nooit van een istream zonder te controleren of de istream wel leesklaar is. Probeer maar eens de statusbits van de istream af te drukken (eof, fail en bad), dan zal je zien dat dat de stream zich in een foutstaat bevindt.
maar ik zet eerst de read pointer terug naar 44 en dan blijft tellg() toch -1 geven voordat de Handle_Function(read); word aangeroepen
PS. read is std::ifstream
Beware of the Raping Zebra's
tellg gaf al -1? Je moet de errorbits wel resetten. Weet zo uit mn hoofd niet hoe, maar is makkelijk te googlen.
ahh, kijk dat verklaard een hoopquote:
tellg gaf al -1? Je moet de errorbits wel resetten. Weet zo uit mn hoofd niet hoe, maar is makkelijk te googlen.
EDIT:
klopt geen ene flikker van m'n code zal dat eerst eens even fixen...
bedankt in ieder geval
[ Bericht 11% gewijzigd door netolk op 02-04-2011 22:26:54 ]
Beware of the Raping Zebra's
ik weet al wat m'n probleem was, vergat te checken of de loop nog wel valide was... maar dat is nu dus gefixed en het werkt gewoon
Beware of the Raping Zebra's
goeden avond fokkers,
ik vraag me af of dit tot geheugen leaks lijd:
word nu bij het deleten van Piece* de destructor van Piece aan geroepen? of moet ik dit regelen in de destructor van LList?
ik vraag me af of dit tot geheugen leaks lijd:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | class Piece{ Piece *_NEXT; std::string _TYPE; std::string _NAME; void *_DATA; }; class LList{ Piece *_START; ~LList(); }; LList::~LList(){ Piece *temp1,*temp2; if(_START != 0){ temp1 = _START; while(temp1 !=0){ temp2 = temp1; temp1 = temp1->_NEXT; delete temp2; } } } |
word nu bij het deleten van Piece* de destructor van Piece aan geroepen? of moet ik dit regelen in de destructor van LList?
Beware of the Raping Zebra's
oke, dat is mooi...quote:
Bij het deleten van Piece* wordt inderdaad de destructor van Piece aangeroepen.
nog een vraagje stel ik hou een int die de grootte van het object voorstelt waar void *_DATA naar verwijst, hoe kan ik *_DATA dan ombouwen zodat het object uit het geheugen geflikkerd word? of is dit niet mogelijk in C++?
Beware of the Raping Zebra's
Je kan gewoon delete _DATA doen, de delete "weet" hoeveel ruimte het object inneemt als je het met new hebt aangemaakt.
um _DATA is wel een void, en als ik delete _DATA doe dan is dat dus ongedefinieerd. Ik krijg dit ook als waarschuwing als ik het wel probeerquote:
Je kan gewoon delete _DATA doen, de delete "weet" hoeveel ruimte het object inneemt als je het met new hebt aangemaakt.
dus ik dacht ik cast het eerst naar de gebruikte grootte en dan delete ik het op die manier
Ik weet alleen niet hoe ik dat moet doen als het object bijv. 30 byte is
Beware of the Raping Zebra's
Dat het void is zou niks uit moeten maken, new en delete wrappen malloc en free, en die werken ook met void pointers.
Maar als je het echt netjes wilt doen kun je ofwel een template maken en void vervangen door een typename binnen die template, of een base class waar je types die _DATA kunnen zijn van afleidt en dan _DATA dus als een pointer naar die base class declareren.
Het enige probleem void pointers is misschien dat er geen destructor wordt aangeroepen, dus alleen gebruiken voor pointers naar "simpele" types waar geen destructor voor nodig is.
Het enige probleem void pointers is misschien dat er geen destructor wordt aangeroepen, dus alleen gebruiken voor pointers naar "simpele" types waar geen destructor voor nodig is.
Dat er evt. geen destructor word aangeroepen is geen probleem dat is nog wel op te lossen maar wat het is ik heb bijv.quote:
Maar als je het echt netjes wilt doen kun je ofwel een template maken en void vervangen door een typename binnen die template, of een base class waar je types die _DATA kunnen zijn van afleidt en dan _DATA dus als een pointer naar die base class declareren.
Het enige probleem void pointers is misschien dat er geen destructor wordt aangeroepen, dus alleen gebruiken voor pointers naar "simpele" types waar geen destructor voor nodig is.
| 1 | int *ptr_int = new int(8); |
| 1 | _DATA = ptr_int; |
Beware of the Raping Zebra's
Ja, dat snapt ie niet, delete zal dan simpelweg ptr_int[0] deleten en de rest laten staan.
delete [] zou dat wel goed moeten doen, maar dan moet je het wel bij arrays houden.
delete [] zou dat wel goed moeten doen, maar dan moet je het wel bij arrays houden.
Gelukkig wordt er ook maar 1 int aangemaakt door new in zijn voorbeeld.quote:
Ja, dat snapt ie niet, delete zal dan simpelweg ptr_int[0] deleten en de rest laten staan.
delete [] zou dat wel goed moeten doen, maar dan moet je het wel bij arrays houden.
goed ik zal de warningcode er wel even bij plakken dan:quote:
[..]
Gelukkig wordt er ook maar 1 int aangemaakt door new in zijn voorbeeld.
| 1 2 | LList.cpp: In destructor `Piece::~Piece()': LList.cpp:3: warning: deleting `void*' is undefined |
Het lijkt er op of de void-pointers geen grootte kunnen "onthouden"
[ Bericht 4% gewijzigd door netolk op 06-04-2011 18:00:32 ]
Beware of the Raping Zebra's
De C++ standaard definieert geen delete van void*s, maar dat betekent niet dat de compiler het niet gedefinieerd heeft.
De code werkt op vrijwel elke compiler goed, zolang de void* naar een built-in type verwijst. Als je hem naar classes laat verwijzen, dan kunnen er dingen misgaan, bijvoorbeeld omdat er dan geen destructor wordt aangeroepen.
Het memory management onthoudt de grootte van de blokken geheugen die worden gealloceerd en weet dus hoe groot het blok geheugen is waar de pointer aan verbonden is.
De code werkt op vrijwel elke compiler goed, zolang de void* naar een built-in type verwijst. Als je hem naar classes laat verwijzen, dan kunnen er dingen misgaan, bijvoorbeeld omdat er dan geen destructor wordt aangeroepen.
Het memory management onthoudt de grootte van de blokken geheugen die worden gealloceerd en weet dus hoe groot het blok geheugen is waar de pointer aan verbonden is.
Ja, maar het is dus nu juist wel de bedoeling om dit oa. ook naar classes ect te laten verwijzenquote:
De C++ standaard definieert geen delete van void*s, maar dat betekent niet dat de compiler het niet gedefinieerd heeft.
De code werkt op vrijwel elke compiler goed, zolang de void* naar een built-in type verwijst. Als je hem naar classes laat verwijzen, dan kunnen er dingen misgaan, bijvoorbeeld omdat er dan geen destructor wordt aangeroepen.
Het memory management onthoudt de grootte van de blokken geheugen die worden gealloceerd en weet dus hoe groot het blok geheugen is waar de pointer aan verbonden is.
dus hoe kan het dan goed opgeruimd worden?
Beware of the Raping Zebra's
| 1 2 3 4 5 6 7 8 9 10 11 12 | class Piece{ Piece *_NEXT; std::string _TYPE; std::string _NAME; }; template<typename T> class TypedPiece: public Piece { T *_DATA; }; |
Zoiets bijvoorbeeld. Of je maakt van _DATA een base class waar je een templated class van afleidt.
Ja, dat moet ik idd hebben txs...
tja de templates heb ik idd nog niet doorgewerkt maar dat zal ik eens even gaan doen dan
Wat je nu als voorbeeld hebt gemaakt kan je dat dan toch als onderdeel van Piece aanroepen?
tja de templates heb ik idd nog niet doorgewerkt maar dat zal ik eens even gaan doen dan
Wat je nu als voorbeeld hebt gemaakt kan je dat dan toch als onderdeel van Piece aanroepen?
| 1 2 3 | Piece myPiece; myPiece._DATA = ptr_int; |
Beware of the Raping Zebra's
Ja, das het voordeel van templates.quote:
Ja, dat moet ik idd hebben txs...
tja de templates heb ik idd nog niet doorgewerkt maar dat zal ik eens even gaan doen dan
Wat je nu als voorbeeld hebt gemaakt kan je dat dan toch als onderdeel van Piece aanroepen?
[ code verwijderd ]
nice, dan ga ik dat hoofdstuk eens even goed doornemen, dat scheelt weer een hoop cast gekut en daarmee waarschijnlijk ook een hoop fouten en geheugen leaks
bedankt voor de hulp Tabit en ralfie
bedankt voor de hulp Tabit en ralfie
Beware of the Raping Zebra's
Ik zou dit wel met accessormethodes aanpakken, niet direct van buiten de klasse in de data peuren.quote:
Ja, dat moet ik idd hebben txs...
tja de templates heb ik idd nog niet doorgewerkt maar dat zal ik eens even gaan doen dan
Wat je nu als voorbeeld hebt gemaakt kan je dat dan toch als onderdeel van Piece aanroepen?
[ code verwijderd ]
Nee, dat is idd ook niet de bedoeling maar Piece is een onderdeel van mijn Linked List class en ik heb het dan zo gemaakt dat het alleen mogelijk is om data te wijzigen via de Linked List classquote:
[..]
Ik zou dit wel met accessormethodes aanpakken, niet direct van buiten de klasse in de data peuren.
Beware of the Raping Zebra's
