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.
Je moet altijd bedenken dat de compiler moet kunnen afleiden hoeveel geheugen een object van je klasse inneemt. Een array als int[][] declareren gaat hem dus niet worden, want de compiler weet dan niet hoe groot de array is. Als je een array van niet van tevoren gedefinieerde grootte wilt aanmaken, moet je dat dus op de heap doen.
Met vectoren werken lijkt me dan het handigst. Wil je dat niet doen, dan zul je array als een int** moeten declareren, in de constructor array = new int*[y] doen en dan in een lus array[i] = new int[x] voor elke i. Vergeet ook niet een delete op al die zaken uit te voeren in je destructor.
.
Met vectoren werken lijkt me dan het handigst. Wil je dat niet doen, dan zul je array als een int** moeten declareren, in de constructor array = new int*[y] doen en dan in een lus array[i] = new int[x] voor elke i. Vergeet ook niet een delete op al die zaken uit te voeren in je destructor.
.
Ik begrijp waarom mijn poging niet werkte, het was even een manier om duidelijk te maken wat ik wilde.
Persoonlijk wil ik ook liever vectoren gebruiken, maar de opdracht wenst dat er een array gebruikt wordt. Morgen toch maar even discussiėren met mijn docent.
Slimme oplossing, zo met de lus. Dat delete voorkomt dat er een memory leak plaatsvindt?
Om nog even andere oplossingen te overwegen. Een constante maken voor y en x, en die te gebruiken bij het declareren? Of een multidimensionale array meegeven als parameter in de constructor en dan op een of andere manier een nieuwe member aanmaken, die niet is gedeclareerd, als dit mogelijk is?
Iig bedankt voor je reactie(s).
Persoonlijk wil ik ook liever vectoren gebruiken, maar de opdracht wenst dat er een array gebruikt wordt. Morgen toch maar even discussiėren met mijn docent.
Slimme oplossing, zo met de lus. Dat delete voorkomt dat er een memory leak plaatsvindt?
Om nog even andere oplossingen te overwegen. Een constante maken voor y en x, en die te gebruiken bij het declareren? Of een multidimensionale array meegeven als parameter in de constructor en dan op een of andere manier een nieuwe member aanmaken, die niet is gedeclareerd, als dit mogelijk is?
Iig bedankt voor je reactie(s).
Ja, delete voorkomt memory leaks.
Een nieuwe member aanmaken kan niet, C++ is geen Python.
. Je kan natuurlijk wel een pointer als member meegeven daar de meerdimensionale array aan plakken. Maar omdat je het type niet kent (hangt nl van de size af) zou dat een void* moeten worden, dat is denk ik nogal lelijk.
Een nieuwe member aanmaken kan niet, C++ is geen Python.
. Je kan natuurlijk wel een pointer als member meegeven daar de meerdimensionale array aan plakken. Maar omdat je het type niet kent (hangt nl van de size af) zou dat een void* moeten worden, dat is denk ik nogal lelijk.
Die discussie ga je verliezen. Je 'moet' leren datastructuren als vectors e.d. zelf te maken, dat is een onderdeel van je opleiding. Je mag bij dit soort opdrachten nooit collections gebruiken.quote:Op zondag 31 oktober 2010 21:42 schreef FastFox91 het volgende:
Persoonlijk wil ik ook liever vectoren gebruiken, maar de opdracht wenst dat er een array gebruikt wordt. Morgen toch maar even discussiėren met mijn docent.
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Je kan het als matrix opslaan, maar ook als een lijst van [x,y,waarde] triplets.
en dan simpelweg een 1-dimensionale array van deze triplets bijhouden en evt. vergroten wanneer nodig. 
Anders zou ik je aanraden een matrix-classe te maken van een vaste grootte met een equals-operator om data over te zetten. Daarna een klasse maken die deze matrices weer gebruikt om een variabele grootte te realiseren:
| 1 2 3 4 | { int x,y,waarde; } |
Anders zou ik je aanraden een matrix-classe te maken van een vaste grootte met een equals-operator om data over te zetten. Daarna een klasse maken die deze matrices weer gebruikt om een variabele grootte te realiseren:
| 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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | { private: int* data; unsigned int width; unsigned int height; public: unsigned int getWidth() const {return width;} unsigned int getHeight() const {return height;} Matrix(unsigned int width, unsigned int height) : width(width), height(height) {data = new int[width * height];} ~Matrix() {delete[] data;} int& get(unsigned int x, unsigned int y) {/* todo: check bounds */ return data[x + y * width];} void copyTo(Matrix& pMatrix) {/* for-next loops to copy data */} }; class VariableMatrix { private: Matrix* MyMatrix; public: VariableMatrix() : MyMatrix(0) {} ~VariableMatrix() {delete MyMatrix;} Get(unsigned int x, unsigned int y) {/*check for zero*/ return MyMatrix.Get(x,y);} Set(unsigned int x, unsigned int y) { if (MyMatrix == 0 || x >= MyMatrix.GetWidth() || y >= MyMatrix.GetHeight()) { Matrix* NewMatrix = new Matrix(x+1, y+1); if (MyMatrix) { MyMatrix.copyTo(NewMatrix); delete MyMatrix; MyMatrix = NewMatrix; } } } }; Let niet op m'n vreselijke stijl en alle fouten. want ik gebruik nu m'n persoonlijke- en werk-stijl doorelkaar. |
@Catbert
Je hebt gelijk gekregen.
@Cruise.Elroy
Dit gaat nog even wat te ver voor mijn niveau en is waarschijnlijk ook wel beetje te veel van het goede voor m'n opdracht. Waarschijnlijk zoek ik in de toekomst je post nog wel eens op.
Je hebt gelijk gekregen.
@Cruise.Elroy
Dit gaat nog even wat te ver voor mijn niveau en is waarschijnlijk ook wel beetje te veel van het goede voor m'n opdracht. Waarschijnlijk zoek ik in de toekomst je post nog wel eens op.
Ik zou er een linked list van matrices van maken denk ik. Krijg je echt enorm leuke code, en nog efficient in geheugengebruik ook. (alleen niet heel snel )
)
Klinkt als een enorme teringzooi, maargoed. Als je een 2D array nodig hebt, moet je niet opeens met rare zaken gaan klooien.quote:Op dinsdag 2 november 2010 11:41 schreef Cruise.Elroy het volgende:
Ik zou er een linked list van matrices van maken denk ik. Krijg je echt enorm leuke code, en nog efficient in geheugengebruik ook. (alleen niet heel snel
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Rare zaken?quote:Op dinsdag 2 november 2010 11:44 schreef Catbert het volgende:
[..]
Klinkt als een enorme teringzooi, maargoed. Als je een 2D array nodig hebt, moet je niet opeens met rare zaken gaan klooien.
Ik zou wss apart verticaal en horizontaal resizen afhandelen, en elk nieuw blok erbij in een linked list zetten. Elk blok kan je dan indexen als elke statische 2D array
[ Bericht 18% gewijzigd door Cruise.Elroy op 02-11-2010 17:54:31 ]
Hoe maak je zo'n linked list dan?quote:
[..]
Rare zaken?
Ik zou wss apart verticaal en horizontaal resizen afhandelen, en elk nieuw blok erbij in een linked list zetten. Elk blok kan je dan indexen als elke statische 2D array
Beware of the Raping Zebra's
Dat bedoel ik dus...quote:
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Oh kom op, een LL is naast een standaard array wel de meest basic manier van data opslaan.
http://en.wikipedia.org/wiki/Linked_list
http://en.wikipedia.org/wiki/Linked_list
Je hoeft mij niet te vertellen wat een linked list is. Het punt is dat hij voor z'n opleiding C++ aan het leren is, en net met arrays begint. Dan zou je moeten snappen dat hij A) de opdracht uit moet voeren zoals beschreven en B) we het niet onnodig complex moeten maken.quote:Op donderdag 4 november 2010 07:54 schreef Cruise.Elroy het volgende:
Oh kom op, een LL is naast een standaard array wel de meest basic manier van data opslaan.
http://en.wikipedia.org/wiki/Linked_list
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Ik vind het wel raar hoor, dat mensen eerst met programmeertalen beginnen en daarna pas met algoritmen en datastructuren. Andersom zou beter zijn.
Het is wat lastig practicumopdrachten uit te voeren als je geen taalen kent waarin je dat uitvoeren kunt doen. Je kunt zoveel theorie leren, maar een DSW tree kunnen implementeren zul je toch echt gewoon een keer moeten doen om 't te snappen.quote:Op donderdag 4 november 2010 10:14 schreef thabit het volgende:
Ik vind het wel raar hoor, dat mensen eerst met programmeertalen beginnen en daarna pas met algoritmen en datastructuren. Andersom zou beter zijn.
Ik heb zelf HBO-I gedaan en wij hadden destijds het probleem dat de het praktijkdeel van het vak C++ verplaatst hadden naar het vak Algorithmen. En toen was opeens de docent C++ ziek en mochten we implementaties van Algorithmen (Huffman / LZW) in C++ doen terwijl we daar nog geen les in hadden gehad. Dat ging ongeveer zo:
CODERDECODE
*compile*
execute!
"SEGMENTATION FAULT. CORE DUMPED"
Wut?
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Praten jullie nog steeds over dat probleempje van mij?
Heeft C++ geen interessantere, van hoger niveau, onderwerpen waarover te discussiėren valt?
Heeft C++ geen interessantere, van hoger niveau, onderwerpen waarover te discussiėren valt?
Nee, C++ is gewoon saai.quote:Op donderdag 4 november 2010 10:45 schreef FastFox91 het volgende:
Praten jullie nog steeds over dat probleempje van mij?
Heeft C++ geen interessantere, van hoger niveau, onderwerpen waarover te discussiėren valt?
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Ow heet dat zo XDquote:
Oh kom op, een LL is naast een standaard array wel de meest basic manier van data opslaan.
http://en.wikipedia.org/wiki/Linked_list
Beware of the Raping Zebra's
Even een vraagje wat kost een lege vector aan geheugen? is dit niks of is dit wel wat en afhankelijk van wat de vector stored?
Beware of the Raping Zebra's
Elk object neemt geheugen in. Hoeveel precies hangt van de implementatie van vector af en is niet door de standaard gedefinieerd. Maar ik neem aan dat een vector toch in elk geval z'n lengte zal opslaan, een pointer naar de beginwaarde en bovendien een stukje geheugen reserveert om dingen in te stoppen (je wil namelijk niet elke keer als je iets in die vector stopt een nieuw stuk geheugen moeten vrijmaken om vervolgens je oude vector daarheen te verplaatsen).
bron: http://social.msdn.micros(...)5b-a739-5cd311bc21c4
.
Leesvoer: http://blogs.msdn.com/b/f(...)ector-data-size.aspx
Wat ik er zelf van weet: elke vector heeft sowieso 3 pointers, de MyFirstIter kan je met elke intellisense-GUI ook wel zien staan, dus dat maakt 16 bytes. Waarom de _Aval 1 byte is weet ik niet want het is een stateloos object.
[ Bericht 4% gewijzigd door Cruise.Elroy op 09-11-2010 10:49:53 ]
Ik heb nog wat lopen spitten, en het lijkt dat er minstens 4 bytes verloren lijken te gaan, iig 3 jaar geleden nog welquote:tried spelunking in STL code that comes with VS2008 SP1 (a.k.a. VC9).
Considering debug builds as per your request, I came to the following conclusions:
In both cases of iterator debugging feature (i.e. _HAS_ITERATOR_DEBUGGING) being enabled or disabled:
1. vector has 3 data members, all pointers. In 32-bit systems, each pointer is 4 bytes, so they occupy 3*4 = 12 bytes.
2. vector is derived from _Vector_val class. This class has an _Alval data member, which is 1 byte big.
However, for alignment reasons, the size cost is rounded to 4 bytes.
So, you have 12 bytes (from 3 vector's pointers) + 4 bytes (from _Vector_val::_Alval) = 16 bytes subtotal.
Now, let's go to sub-cases of iterator debugging feature enabled or disabled.
If iterator debugging feature is enabled:
3a. _Vector_val derives from _Container_base_secure. _Container_base_secure has a data member _Myfirstiter, which is a pointer, so add 4 bytes.
The total becomes: 16 + 4 = 20 bytes (as per your finding).
If iterator debugging feature is disabled:
3b. _Vector_val derives from _Container_base_aux_alloc_real. _Container_base_aux_alloc_real has one data member. Its size is 1 byte, but for alignment reasons rounds up to 4 bytes.
4b. _Container_base_aux_alloc_real derives from _Container_base_aux. _Container_base_aux has one data member _Myownedaux, which is a pointer; so: add 4 bytes.
In this case the total becomes: 16 + 4 + 4 = 24 bytes (as per your finding).
You may want to try this simple C++ program I wrote to try to better understand the total size of STL vector.
. Leesvoer: http://blogs.msdn.com/b/f(...)ector-data-size.aspx
Wat ik er zelf van weet: elke vector heeft sowieso 3 pointers, de MyFirstIter kan je met elke intellisense-GUI ook wel zien staan, dus dat maakt 16 bytes. Waarom de _Aval 1 byte is weet ik niet want het is een stateloos object.
[ Bericht 4% gewijzigd door Cruise.Elroy op 09-11-2010 10:49:53 ]
oke bedankt voor de info... Bedacht later hčhč dat ik het ook via sizeof had kunnen weten 
@Cruise.Elroy txs voor de extra info
@Cruise.Elroy txs voor de extra info
Beware of the Raping Zebra's
sizeof laat natuurlijk alleen de ruimte zien die het object zelf inneemt, niet de extra geheugenruimte die het reserveert.
Je mag van STL verwachten dat een lege container geen heap gaat aanspreken.quote:Op dinsdag 9 november 2010 14:00 schreef thabit het volgende:
sizeof laat natuurlijk alleen de ruimte zien die het object zelf inneemt, niet de extra geheugenruimte die het reserveert.
Grappig genoeg gebeurt dit wel op de PS3 of X360 (weet niet meer welke)
Das best wel slecht... wel grappig iddquote:
[..]
Je mag van STL verwachten dat een lege container geen heap gaat aanspreken.
Grappig genoeg gebeurt dit wel op de PS3 of X360 (weet niet meer welke)
Beware of the Raping Zebra's
Het levert echt vreselijke bugs op als je multi-platform en met heap management werkt.quote:
[..]
Das best wel slecht... wel grappig idd
Vraagje als je een library in je compiler ramt compiled die dan compleet mee of alleen de stukken code die je daadwerkelijk gebruikt?
Beware of the Raping Zebra's
Je compiler? Je linker bedoel je. Als je statisch linked wordt alles meegenomen.
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Hčhč ja dat bedoel ik ja... oké dus als je maar 1 functie nodig hebt kun je die beter apart in een cpp file zetten en die compilen +linken?quote:
Je compiler? Je linker bedoel je. Als je statisch linked wordt alles meegenomen.
Beware of the Raping Zebra's
Ja maar dat klinkt al moeilijk XDquote:
Op ik gebruik minGW kan die dat überhaupt wel?
Beware of the Raping Zebra's
Je kan de libraries vast wel in een DLL stoppen, maar het beste antwoord op zulke vragen blijft nog altijd: RTFM.quote:
[..]
Ja maar dat klinkt al moeilijk XD
ik gebruik minGW kan die dat überhaupt wel?
.
Ja, nou beetje dll's maken... dan plak ik de code die ik nodig heb wel gewoon ff in een cpp bestandje die ik dan ff aan mn linker mee geef...
bedankt in ieder geval
bedankt in ieder geval
Beware of the Raping Zebra's
Let wel dat DLLs dynamisch linken, als je gewoon statisch linkt dan zal de linker slim knippen/plakken en alleen de dingen meenemen die het nodig heeft. Maareh, is de grootte van je exe zo belangrijk?
Compileren van libraries doet hij sowieso niet, want die zijn als het goed is al gecompileerd. Of heb je het over .h files toevoegen?
Die worden als het goed is allemaal in pre-compiled headers gezet als je dat aanzet, en zullen sowieso niet meer dan een syntax-check krijgen als je ze niet gebruikt.
Compileren van libraries doet hij sowieso niet, want die zijn als het goed is al gecompileerd. Of heb je het over .h files toevoegen?
Die worden als het goed is allemaal in pre-compiled headers gezet als je dat aanzet, en zullen sowieso niet meer dan een syntax-check krijgen als je ze niet gebruikt.
Bovendien, wat boeit het dat je executable wat groter wordt?
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Hij heeft het volgens mij over compile-tijden. Dan maakt het niet uit of je statisch of dynamisch linkt, de libraries zelf zijn natuurlijk al gecompileerd.quote:
Bovendien, wat boeit het dat je executable wat groter wordt?
Normaal hercompile je alleen de code die gewijzigd is. Als je voor elke build alles opnieuw compiled doe je sowieso iets niet goed.quote:
Hij heeft het volgens mij over compile-tijden. Dan maakt het niet uit of je statisch of dynamisch linkt, de libraries zelf zijn natuurlijk al gecompileerd.
Daarnaast gaf 'ie na mijn reactie aan dat het om het linken ging, en linken gaat sowieso heel snel.
"[...] a large number of the teenagers claiming Asperger's are, in fact, merely dicks."
Linken is in mijn ervaring vaak een traag onderdeel omdat je het moeilijk distributed kan doen (iaw, er zijn weinig pakketten die dat ondersteunen) tenzij ik moduleinterfaces ga veranderen is linken snel 50% van de buildtijd.quote:
[..]
Normaal hercompile je alleen de code die gewijzigd is. Als je voor elke build alles opnieuw compiled doe je sowieso iets niet goed.
Daarnaast gaf 'ie na mijn reactie aan dat het om het linken ging, en linken gaat sowieso heel snel.
Dat terwijl dat hele gebeuren van headers includen, compilen en linken bedoeld was om het snel te laten werken. In deze tijd van snelle processoren en parallellisatie vertraagt het de boel alleen maar. Een soort QWERTY-achtige taferelen dus.quote:
[..]
Linken is in mijn ervaring vaak een traag onderdeel omdat je het moeilijk distributed kan doen (iaw, er zijn weinig pakketten die dat ondersteunen) tenzij ik moduleinterfaces ga veranderen is linken snel 50% van de buildtijd.
Het vertraagt niets, juist door het losse compilen en linken, headerfiles etc. kan je goed gebruikmaken van parallelisatie. Helaas moet het toch ergens bijelkaar komen.
ik bedoelde idd linken, ja...
Op zich maakt het niet zo veel uit als mn .exe iets groter word maar hou er niet van als er onnodig geheugen gebruikt word.. en ik vind de lib echt bagger maar er zitten 1 of 2 handige functies in die ik soms gebruik voordat ik er een win32 programma van een console maak
Op zich maakt het niet zo veel uit als mn .exe iets groter word maar hou er niet van als er onnodig geheugen gebruikt word.. en ik vind de lib echt bagger maar er zitten 1 of 2 handige functies in die ik soms gebruik voordat ik er een win32 programma van een console maak
Beware of the Raping Zebra's
Enige geheugenverbruik dat je hebt is dat de exe die moet worden ingeladen iets groter is. Een lib zelf bestaat eigenlijk altijd puur uit instructies en gebruikt geen extra resources ofzo, misschien een static var hier en daar, maar dat is echt te verwaarlozen denk ik.
Goedenavond Fokkers,
Ik vraag me af waarom de volgende code flipt..
Het progje runt tot het einde/begin van catch(Error e) weet iemand waardoor dit komt? de constructor van class Game Werkt zoals zou horen (dus zonder fouten dat heb ik al gecheckt) maar ik snap maar niet waarom hij aan het einde/begin van catch vast loopt...
Ik vraag me af waarom de volgende code flipt..
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | #include "Error.h" #include "Game.h" #include <iostream> #include <Windows.h> int main(){ srand(unsigned(time(0))); rand(); // voorkomt dat het 1e getal altijd hetzelfde is try{ // het stuk waar Game gebruikt kan worden Game myGame("01.lvl","01.opt"); //myGame.run(); // gameloop } catch(Error e){ std::cerr << e._DATA << '\n'; } std::cout << "?\n"; return 0; } |
Het progje runt tot het einde/begin van catch(Error e) weet iemand waardoor dit komt? de constructor van class Game Werkt zoals zou horen (dus zonder fouten dat heb ik al gecheckt) maar ik snap maar niet waarom hij aan het einde/begin van catch vast loopt...
Beware of the Raping Zebra's
Sorry vergeten er bij te zetten maar dat is een const char* waar ik dan een string in stop, maar er word dus geen throw Error gedaan...quote:
Kom er net achter dat het niet perse aan try catch deel ligt.. als ik dat er uit haal dan krijg ik wel de vraagteken te zien er onderstaat maar daarna flipt ie nog steeds...
Beware of the Raping Zebra's
Misschien is het handiger om je couts met endl te eindigen, dan weet je zeker dat de buffer wordt geflusht. Maar goed, grote kans dat er toch een fout in de constructor van Game zit dan.
De Game constructor gebruikt wel ifstream get(), volgens cplusplus.com dat er std::ios_base::failure word ge-trowed. maar die vang ik af(als het goed is)
dus de code is dan dit:
dus de code is dan dit:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Game::Game(const char* lvlfile,const char* optfile){ // load from file /* _OPTIONS = Options(optfile); */ std::ifstream Read(lvlfile,std::ios::binary); if(Read.is_open()){ BitField::I16 rI16; BitField::I32 rI32; try{ // read data from file } catch(std::ios_base::failure){ Read.close(); throw Error("File Corrupted"); } Read.close(); } else throw Error("Can't open Lvl File"); } |
Beware of the Raping Zebra's
Misschien moet je wat couts in je code plaatsen ter debugging (wel met endl eindigen anders komen ze misschien niet op het scherm). Zo kun je zien wat er waar gebeurt.
Heb ik dus gedaan en alles word tot en met onder aan de try uit gevoerd en de catch word niet aangeroepen, wat wel zou moeten aangezien het bestand minder data bevat dan ik probeer te lezen dus zou er een ios_base::failure moeten zijn maar die word dus niet ge-trowed...quote:
Misschien moet je wat couts in je code plaatsen ter debugging (wel met endl eindigen anders komen ze misschien niet op het scherm). Zo kun je zien wat er waar gebeurt.
Beware of the Raping Zebra's
