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.
hmm, dan werkt mn code niet zoals ik zou verwachten...
ik heb nu dus
en
ik blijf echter nog steeds een error krijgen bij het versturen van data
ik heb nu dus
| 1 | HANDLE Thread = CreateThread(0,0,Threader,&hClient,0,0); |
en
| 1 2 3 4 5 6 7 8 9 10 11 | unsigned long WINAPI Threader(void *Data){ std::cout << "Threader\n"; SOCKET Client = *(SOCKET*)(&Data); char Buffer[2] = {'1','2'}; if((send(Client,Buffer,2,0)) == SOCKET_ERROR) throw Error("Socket error while sending!"); if(Client != INVALID_SOCKET) closesocket(Client); } |
ik blijf echter nog steeds een error krijgen bij het versturen van data
Beware of the Raping Zebra's
| 1 2 3 4 5 6 7 | SOCKET hClient = INVALID_SOCKET; sockaddr_in ClientSockAddr = {0}; int ClientSockSize = sizeof(ClientSockAddr); hClient = accept(hSocket,reinterpret_cast<sockaddr*>(&ClientSockAddr),&ClientSockSize); if(hClient == INVALID_SOCKET) throw Error("Accept function failed!"); HANDLE Thread = CreateThread(0,0,Threader,&hClient,0,0); |
Beware of the Raping Zebra's
Het volgende is ook een erg rare cast:
Data is al een pointer. &Data levert dus het adres van een pointer. Dit cast je naar een Socket-pointer. En die dereference je. De compiler denkt nu dus dat het een Socket is, terwijl je eigenlijk een Socket-pointer hebt.
Probeer het volgende eens:
En let op dat de hClient nog steeds op de stack in main() staat: als hij hier uit scope raakt of overschreven wordt, dan ben je je gegevens kwijt en crasht de boel (dus beter advies is dynamisch alloceren).
| 1 | SOCKET Client = *(SOCKET*)(&Data); |
Data is al een pointer. &Data levert dus het adres van een pointer. Dit cast je naar een Socket-pointer. En die dereference je. De compiler denkt nu dus dat het een Socket is, terwijl je eigenlijk een Socket-pointer hebt.
Probeer het volgende eens:
| 1 | SOCKET Client = *reinterpret_cast<SOCKET *>(Data); |
En let op dat de hClient nog steeds op de stack in main() staat: als hij hier uit scope raakt of overschreven wordt, dan ben je je gegevens kwijt en crasht de boel (dus beter advies is dynamisch alloceren).
"Slechts diegene mag slopen die iets beters kan bouwen."
hmm, wat ik dus probeerde was met die cast er voor zorgen dat de compiler idd denkt dat het een socket is en die vervolgens kopieert naar de socket in the nieuwe threadquote:Op donderdag 10 maart 2011 22:17 schreef GS42 het volgende:
Het volgende is ook een erg rare cast:
[ code verwijderd ]
Data is al een pointer. &Data levert dus het adres van een pointer. Dit cast je naar een Socket-pointer. En die dereference je. De compiler denkt nu dus dat het een Socket is, terwijl je eigenlijk een Socket-pointer hebt.
Probeer het volgende eens:
[ code verwijderd ]
En let op dat de hClient nog steeds op de stack in main() staat: als hij hier uit scope raakt of overschreven wordt, dan ben je je gegevens kwijt en crasht de boel (dus beter advies is dynamisch alloceren).
Beware of the Raping Zebra's
Tsja, maar als de compiler denkt een Socket te hebben terwijl het eigenlijk het adres van een Socket is, kunnen er natuurlijk geen goede dingen gebeuren.quote:hmm, wat ik dus probeerde was met die cast er voor zorgen dat de compiler idd denkt dat het een socket is en die vervolgens kopieert naar de socket in the nieuwe thread
Sowieso is een nieuw kopie maken in Threader() onveilig, omdat er geen garantie is dat het object nog bestaat ten tijde van kopieren (tenzij jij die garantie als programmeur geeft d.m.v mutex locks of iets dergelijks).
"Slechts diegene mag slopen die iets beters kan bouwen."
ja das waar miss is het beter om dan de sockets in een array oid. te stoppen dynamisch geheugen alloceren zodat de treads er gebruik van kunnen makenquote:
[..]
Tsja, maar als de compiler denkt een Socket te hebben terwijl het eigenlijk het adres van een Socket is, kunnen er natuurlijk geen goede dingen gebeuren.
Sowieso is een nieuw kopie maken in Threader() onveilig, omdat er geen garantie is dat het object nog bestaat ten tijde van kopieren (tenzij jij die garantie als programmeur geeft d.m.v mutex locks of iets dergelijks).
Beware of the Raping Zebra's
| 1 2 3 4 5 6 7 8 | SOCKET *Clients[number]; // code for(int i = 0; i < number; i++){ delete [] Clients[i]; Clients[i]=0; } |
kan bij die delete de brakkets ("[]") weggelaten worden?
Beware of the Raping Zebra's
Het moet zelfs, want je delete geen gealloceerde array van Sockets, maar één enkele. In het algemeen geldt: alleen met delete[] verwijderen als je met new[] gealloceerd hebt.quote:
kan bij die delete de brakkets ("[]") weggelaten worden?
Je bovenstaande code is gevaarlijk omdat het gedrag ongedefinieerd is: per implementatie kan het resultaat verschillen (en waarschijnlijk segfaulten).
"Slechts diegene mag slopen die iets beters kan bouwen."
oke, ik snap die brakkets nu maar waarom waarom is het gedrag ongedefinieerd dan?quote:
[..]
Het moet zelfs, want je delete geen gealloceerde array van Sockets, maar één enkele. In het algemeen geldt: alleen met delete[] verwijderen als je met new[] gealloceerd hebt.
Je bovenstaande code is gevaarlijk omdat het gedrag ongedefinieerd is: per implementatie kan het resultaat verschillen (en waarschijnlijk segfaulten).
Beware of the Raping Zebra's
TL;DR versie: Omdat C++ niet beschrijft hoe deze situatie afgehandeld moet worden.quote:
oke, ik snap die brakkets nu maar waarom waarom is het gedrag ongedefinieerd dan?
Lange versie: De programmeertaal 'C++' wordt ontwikkeld door een groep mensen die precies omschrijft wat C++ moet kunnen en doen. Deze groep maakt echter geen compilers, maar alleen een beschrijving van de taal. Compilerbouwers (zoals Microsoft, GCC, Borland etc.) gebruiken deze beschrijving en moeten deze precies volgen als ze een C++-compiler willen maken.
Niet alles staat echter in beschrijving van de taal (ook wel 'standaard' genoemd). Bijvoorbeeld het onderstaande stukje beschrijft de de memberfunctie sum() van de std::valarray class:
Hierin staat dus precies wat std::valarray::sum() moet doen. Het interessante stuk is dikgedrukt. Omdat niet is gedefinieerd wat de functie moet doen als lengte = 0, kan dit verschillen per compilerbouwer. Ze kunnen er bijvoorbeeld voor kiezen te segfaulten, een exception te gooien of gewoon '0' terug te geven als resultaat. Het punt is: ze kunnen kiezen.quote:T sum () const ;
This function may only be instantiated for a type T to which operator+= can be applied. This function returns the sum of all the elements of the array.
If the array has length 0, the behavior is undefined. If the array has length 1, sum() returns the value of element 0. Otherwise, the returned value is calculated by applying operator+= to a copy of an element of the array and all other elements of the array in an unspecied order.
Als je dus goede C++ code wilt schrijven, moet je zorgen dat je nooit sum() gebruikt van een leeg std::valarray object: je weet immers niet wat er gaat gebeuren. Je kunt wel testen wat er met jouw compiler gebeurt, maar je weet dan nog niet (a) of dit met iets andere code ook zo zal zijn, (b) of dit in een andere versie van jouw compiler (ouder/nieuwer) ook zo zal zijn en al helemaal niet of (c) dit met een andere compiler ook werkt.
Het resultaat van delete[] op een gewone pointer is ook zoiets: het effect van die operatie staat niet in de standaard, dus moet je er niet vanuit gaan dat het werkt. Dat wordt bedoeld met 'ongedefinieerd gedrag': het resultaat van een operatie die niet in de standaard staat en dus per implementatie kan verschillen.
[ Bericht 0% gewijzigd door GS42 op 13-03-2011 12:21:25 ]
"Slechts diegene mag slopen die iets beters kan bouwen."
oke, dus dat was het ongedefinieerde deel 
, dus zonder [] is het wel correcte taal dus 
, dus zonder [] is het wel correcte taal dus
Beware of the Raping Zebra's
Niet specifiek C++ deze vraag, maar is het mogelijk de handle van een control te krijgen (bv een textbox) in flash?
Aangezien ze voor zover ik kan zien geen eigen hWnd hebben.
Aangezien ze voor zover ik kan zien geen eigen hWnd hebben.
'And I called your name,
like an addicted to cocaine calls for the stuff he'd rather blame'
like an addicted to cocaine calls for the stuff he'd rather blame'
het moet mogelijk zijn aangezien Windows ook het een en ander moet weten over de textbox oid.
zoals grootte, locatie ect.
ik zou het alleen niet weten hoe je dit kan vinden er zijn denk ik wel tooltjes voor die dat voor je kunnen vinden
zoals grootte, locatie ect.
ik zou het alleen niet weten hoe je dit kan vinden er zijn denk ik wel tooltjes voor die dat voor je kunnen vinden
Beware of the Raping Zebra's
Ok weet niet of iemand me kan helpen maar ik waag maar de gok
Ik wil graag libHaru, een opensource pdf library, compilen naar een dll. Op de wiki documentatie zeggen ze dat je het volgende moet doen voor windows:
- unzip libharu-X.X.X.zip
- cd libharu-X.X.X
- Microsoft VC++ Compiler: nmake -f script/Makefile.msvc_dll demo
Nu heb ik dat gedaan alleen krijg ik steeds een error:
Iemand enig idee hoe ik dit oplos? Ben niet echt bekend met het compilen van dll's en makefiles.
De code is hier te downloaden, niet van http://libharu.org/ zelf want dan mis je een aantal dirs.
De makefile
Ik wil graag libHaru, een opensource pdf library, compilen naar een dll. Op de wiki documentatie zeggen ze dat je het volgende moet doen voor windows:
- unzip libharu-X.X.X.zip
- cd libharu-X.X.X
- Microsoft VC++ Compiler: nmake -f script/Makefile.msvc_dll demo
Nu heb ik dat gedaan alleen krijg ik steeds een error:
Blijkbaar kan hij een header zlib niet vinden. Ik geloof dat deze bij de zlib hoort, http://zlib.net/. Alleen lees ik nergens in de documentatie dat je die ook moet hebben. Ook lijkt het als of je http://www.libpng.org/pub/png/ nodig hebt... ook hier lees ik niets van in de documentatie...quote:Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
Copyright (C) Microsoft Corporation. All rights reserved.
cl -Fosrc\hpdf_streams.obj /MD -nologo -O2 -Iinclude -Iwin32\include -
I"../../libpng"\include -I"../../zlib"\include -DHPDF_DLL_MAKE -c src\hpdf_strea
ms.c
hpdf_streams.c
src\hpdf_streams.c(28) : fatal error C1083: Cannot open include file: 'zlib.h':
No such file or directory
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 10.0\VC\BI
N\cl.EXE"' : return code '0x2'
Stop.
Iemand enig idee hoe ik dit oplos? Ben niet echt bekend met het compilen van dll's en makefiles.
De code is hier te downloaden, niet van http://libharu.org/ zelf want dan mis je een aantal dirs.
De makefile
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.
Dale, heb je geprobeerd de preprocess-flag LIBHPDF_HAVE_NOZLIB te definieren? Als ik de code in /src/hpdf_streams.c doorblader, krijg ik het idee dat er dan gecompileerd wordt zonder zlib-functionaliteit (wat dat ook in moge houden...).
Zoniet, dan lijkt het erop dat je inderdaad de zlib library nodig hebt op je systeem.
Zoniet, dan lijkt het erop dat je inderdaad de zlib library nodig hebt op je systeem.
"Slechts diegene mag slopen die iets beters kan bouwen."
hey, ik ben bezig met een linked list dinges te maken....
ik heb de volgende code:
ik heb de volgende code:
SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.en dan heb ik hier de niet gedefinieerde functies gedefinieerd:SPOILEROm spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.nu is het zo dat ik dit doe
1
2
3
4LList myLList(mypiece);
std::cout << "List length: " << myLList.lenght() << '\n';
std::cout << "List loop?: " << myLList.loop() << '\n';
dit is mijn output:
1 list lenght: 5
dan krijg ik een error dat het programma niet meer werkt...
dit duid er dus op dat m'n length() functie niet goed opgeruimd word of zo, iemand een idee wat ik niet goed doe?Beware of the Raping Zebra's
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?)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.
"Slechts diegene mag slopen die iets beters kan bouwen."
umm, hij word geïnitialiseerd bij de constructie, en weer vernietigd tijdens de destructie van LListquote:
[..]
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:
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
| Forum Opties | |
|---|---|
| Forumhop: | |
| Hop naar: | |