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.
Das best wel slecht... wel grappig iddquote:Op dinsdag 9 november 2010 14:04 schreef Cruise.Elroy het volgende:
[..]
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
