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.
Het topic over de programmeertalen C en C++. Als je vragen over C of C++ hebt, zit je hier goed. Natuurlijk kan je ook gewoon mee kletsen.
Let er bij het stellen van een vraag op dat je zo veel mogelijk revelante informatie geeft, zoals:
- wat je probeert te doen;
- welk besturingsysteem je hebt;
- welke compiler en versie je gebruikt;
- de eventuele foutmelding die je ziet;
- een minimaal codevoorbeeld dat je fout veroorzaakt.
FAQ
Wat is het verschil tussen C en C++?
De programmeertalen C en C++ hebben veel overeenkomsten. C++ is begonnen als een uitbreiding op C en ondersteunt bijna de volledige C-taal. Dit betekent dat een computerprogramma geschreven in C meestal ook een geldig C++-programma is.
C++ heeft onderdelen aan de C-taal toegevoegd en ondersteunt verschillende programmeerstijlen beter. C++ heeft onder andere sterkere typechecking, betere manieren om data te encapsuleren en eenvoudigere structuren om algemene code te schrijven. C is echter nog steeds beter ondersteund op 'afwijkende' platformen en wordt mede daarom nog veel gebruikt.
Zie Stroustrups FAQ voor meer informatie.
Ik wil beginnen met C of C++; welke moet ik kiezen?
Dat hangt van jou af: er is geen direct 'betere' keuze. Je hoeft zeker geen C te leren voordat je aan C++ begint: het is waarschijnlijk zelfs beter van niet. Zorg in de eerste plaats voor een goed leerboek, de online informatie en 'cursussen' laat vaak te wensen over voor de beginneling.
Wat is een goed boek voor C of C++
Zie wederom Stroustrups FAQ.
Links
Naslagwerken
C/C++ Reference
The C Library Reference Guide
C++ Documentation
C++ Annotations
Achtergrond
The Association of C and C++ Users
Stroustrup's homepage
Deze OP vind je hier.
Robert Moog died for our synths
Je hebt deels gelijk. Maar momenteel gebruik ik ook nog best een flink aantal OpenCV functies die ik er op termijn uit wil mikken. Voorbeeld hiervan is dat ik met Opencv gelijk een eenvoudige grafische output heb. Andere dingen die ik nu nog gebruik zijn alle gemakken die bij OpenCV zitten zoals resize functie, transpose, floodfill...quote:Op maandag 9 december 2013 10:56 schreef Ai_KaRaMBa het volgende:
Ik mis een betje waarom je uberhaubt met OpenCV matrices aan het werken bent. Je lijkt de matrix te 'misbruiken' als canvas van 320x240 pixels, en daarmee ben je opzoek naar optimalisaties omdat het blijkbaar niet snel genoeg is? Wat doet OpenCV preceis voor je in deze casus?
Ik zou zeggen dat als je een 'echte' canvas alloceerd (aaneengesloten blok geheugen, wat een twee-dimensionale array van (signed) integers representeerd), dat dat veel sneller en overzichtelijker werkt?
[ code verwijderd ]
Ik ben bezig met een Depth Sensor van Xtion. Die gebruikt OpenNI, en dan is het wel makkelijk om direct zijn data in een OpenCV container te flikkeren. Maar je hebt wel gelijk denk ik, wellicht is het beter dat hele OpenCV er tussenuit te gooien.
Maar als die eerste statement leeg is haalt de compiler m weg?quote:Op maandag 9 december 2013 11:00 schreef Gehenna het volgende:
[..]
oh wacht daar heb je gelijk in idd (Ik ben net wakker), hij gaat bij die 2e natuurlijk de alle statements door als waarde==0. Dan zou idd die eerste wellicht de betere keuze zijn..
Ik ken OpenCV verder niet, maar als je daarin integer matrices kan definieren, en je kan idd direct de elementen adresseren (zonder de [] overload bij iedere access aan te hoeven roepen), is dat natuurlijk effectief hetzelfde.
Echter, wat je een aantal posts geleden aangaf, is dat 1 keer een pointer fetchen en de ++en in een loop niet lijkt te werken...
Echter, wat je een aantal posts geleden aangaf, is dat 1 keer een pointer fetchen en de ++en in een loop niet lijkt te werken...
Nee ik las verkeerquote:
[..]
Maar als die eerste statement leeg is haalt de compiler m weg?
Hier wel:
| 1 2 3 4 | If (A) //Doe niets if(B) DoeIets() |
maar hier niet:
| 1 2 3 4 | if (A) //Doe niets else if (B) DoeIets() |
Robert Moog died for our synths
Dat lijkt inderdaad niet te werken. Per rij een pointer fetchen wel. Maar kan aan mij liggenquote:
Ik ken OpenCV verder niet, maar als je daarin integer matrices kan definieren, en je kan idd direct de elementen adresseren (zonder de [] overload bij iedere access aan te hoeven roepen), is dat natuurlijk effectief hetzelfde.
Echter, wat je een aantal posts geleden aangaf, is dat 1 keer een pointer fetchen en de ++en in een loop niet lijkt te werken...
Dat maakt volgens mij niets (of nauwelijks iets) uit. Branch prediction in de CPU zorgt ervoor dat je daar niet op deze manier overna hoeft te denken. (de CPU weet welke jumps er vaak en minder vaak worden genomen, en zal verder 'vooruit werken' in het pad waarin hij denkt te gaan springen.quote:
[..]
Maar als die eerste statement leeg is haalt de compiler m weg?
Dat ook nog eens iddquote:
[..]
Dat maakt volgens mij niets (of nauwelijks iets) uit. Branch prediction in de CPU zorgt ervoor dat je daar niet op deze manier overna hoeft te denken. (de CPU weet welke jumps er vaak en minder vaak worden genomen, en zal verder 'vooruit werken' in het pad waarin hij denkt te gaan springen.
Robert Moog died for our synths
Dummy vraag 4.
Als ik bv een loop heb die 10k keer loopt.
In die loop zit vanalles maar ook dit
Loop moet niet gebreakt worden als true want er gebeurt nog vanallerlei dingen.
Dit betekent natuurlijk wel dat somestatement in potentie (bij bijvoorbeeld de helft van de loops) op true gezet wordt. Ook al is ie dit al. De binnenkant van de IF wordt dus vaak bezocht en loopafhankelijkewaarde>iets onnodig vaak geevalueerd.
Klopt dan de volgende gedachte dat dit 'optimaler' is?
Nu kom je maar 1 x aan de binnenkant van de if terecht, feitelijk, en de eerste is check in de if is nogal goedkoop.
Als ik bv een loop heb die 10k keer loopt.
In die loop zit vanalles maar ook dit
| 1 2 3 4 | if (loopafhankelijkewaarde>iets) { somestatement=true; } |
Loop moet niet gebreakt worden als true want er gebeurt nog vanallerlei dingen.
Dit betekent natuurlijk wel dat somestatement in potentie (bij bijvoorbeeld de helft van de loops) op true gezet wordt. Ook al is ie dit al. De binnenkant van de IF wordt dus vaak bezocht en loopafhankelijkewaarde>iets onnodig vaak geevalueerd.
Klopt dan de volgende gedachte dat dit 'optimaler' is?
| 1 2 3 4 | if (somestatement==false && loopafhankelijkewaarde>iets) { somestatement=true; } |
Nu kom je maar 1 x aan de binnenkant van de if terecht, feitelijk, en de eerste is check in de if is nogal goedkoop.
Tegenwoordig is dat echt niet meer te zeggen. Dit soort minimale veranderingen hebben waarschijnlijk sowieso geen invloed op je runtijd, maar met de optimalisaties die de compiler doet en de optimalisaties die de CPU er nog bovenop doet, is er werkelijk geen zinnig woord over te zeggen.quote:
Klopt dan de volgende gedachte dat dit 'optimaler' is?
Als de code al snel genoeg is: zo simpel mogelijk laten. Als de code nog niet snel genoeg is: profilen. Leer te werken met een profiler (e.g. gprof) en gebruik die om te beslissen welke veranderingen je doorvoert.
"Slechts diegene mag slopen die iets beters kan bouwen."
Wat gs42 zegt. En bekijk ook eens de assembler output van je compiler: dat geeft ook een hoop inzicht in wat er gebeurt en wat bepaalde wijzigingen voor impact hebben.
Om terug te komen op je vraag, doe het zo:
Om terug te komen op je vraag, doe het zo:
| 1 2 | If(loopwaarde == iets) Somestatement = true; |
Ik ga dat met zo een profiler eens een keer proberen. Nooit geweten.quote:
Wat gs42 zegt. En bekijk ook eens de assembler output van je compiler: dat geeft ook een hoop inzicht in wat er gebeurt en wat bepaalde wijzigingen voor impact hebben.
Om terug te komen op je vraag, doe het zo:
[ code verwijderd ]
Wat betreft de 'doe het zo' : dat is toch hetzelfde gewoon als met { } ?
Als ik moest gokken, denk ik dat dit het snelste is:quote:
Om terug te komen op je vraag, doe het zo:
| 1 | somestatement |= loopafhankelijkewaarde > iets; |
Aangenomen dat somestatement een bool is. Zo kan je een branch eruit halen en vervangen door een bitwise operator. Maar zoals ik al zei: geen idee of het werkelijk sneller is. Het zou me ook niets verbazen als een if sneller blijkt te zijn, bijv. door branch prediction. Altijd profilen voordat je iets "optimaliseert".
In ieder geval maak je hiermee je code een stuk minder duidelijk.
[ Bericht 2% gewijzigd door GS42 op 10-12-2013 16:55:10 ]
"Slechts diegene mag slopen die iets beters kan bouwen."
Profilen moet ik nog even induiken. Lees het een beetje door en ziet er toch ingewikkeld uitquote:
[..]
Als ik moest gokken, denk ik dat dit het snelste is:
[ code verwijderd ]
Aangenomen dat somestatement een bool is. Zo kan je een branch eruit halen en vervangen door een bitwise operator. Maar zoals ik al zei: geen idee of het werkelijk sneller is. Het zou me ook niets verbazen als een if sneller blijkt te zijn, bijv. door branch prediction. Altijd profilen voordat je iets "optimaliseert".
In ieder geval maak je hiermee je code een stuk minder duidelijk.
De basics zijn best eenvoudig. Je krijgt vrij snel inzicht waarmee je programma het meest mee bezig isquote:
[..]
Profilen moet ik nog even induiken. Lees het een beetje door en ziet er toch ingewikkeld uit
Gebruik je een IDE? Wellicht dat deze ook wel wat profiling functies in huis heeft
Robert Moog died for our synths
Netbeans in ubuntuquote:
[..]
De basics zijn best eenvoudig. Je krijgt vrij snel inzicht waarmee je programma het meest mee bezig is
Gebruik je een IDE? Wellicht dat deze ook wel wat profiling functies in huis heeft
Nee, het verschil zat in de '==' ipv de '>'. Dat was onder de aanname dat loopvariabbele in stapjes van 1 oploopt (wat vaak zo is). Als je loop dat niet doet, is het waarschijnlijk zo'n complexe loop dat het herschrijven van de conditie toch geen significante optimalisatie is...quote:
[..]
Ik ga dat met zo een profiler eens een keer proberen. Nooit geweten.
Wat betreft de 'doe het zo' : dat is toch hetzelfde gewoon als met { } ?
Ubuntu blijkt alleen intern te profilen voor Java.quote:
[..]
De basics zijn best eenvoudig. Je krijgt vrij snel inzicht waarmee je programma het meest mee bezig is
Gebruik je een IDE? Wellicht dat deze ook wel wat profiling functies in huis heeft
Heb nog een nieuw vraagstukje: Dummy vraag 5 alweer!
| 1 2 | double& angle = Par.Xtion.SensorAngle; double angle = Par.Xtion.SensorAngle; |
Bij optie nummer 1 verandert de Par.Xtion.sensorangle als angle aangepast wordt. Bij optie nummer 2 niet. Is het over het algemeen beter om optie 2 te gebruiken als je niet van plan bent Par.Xtion.sensorangle aan te passen? En als ik 'angle' sowieso niet aanpas, maakt de compiler er dan stiekem sowieso een reference van?
as in: daar zit waarschijnlijk ook minimaal verschil in als je miljoenmiljard keer berekeningen doet met waarde angle? De eerste maakt een verwijzing, de tweede kopieert daadwerkelijk de data. Ik kan mij voorstellen dat als de data een dikke vette matrix is het aantrekkelijker wordt om altijd met & te werken, maar hoe zit dat als het gewoon een int waarde is, bijvoorbeeld?
Mijns inziens is nr 2 de standaard manier. References gebruik ik nooit in zo'n situatie. Het is vervelend als je overal in je code references naar (private) member data achterlaat. Maakt debuggen lastig (huh? wie heeft die angle aangepast??) en druist tegen de principes van OOP in.
Wat betreft performance maakt het niets uit, daar zorgt de compiler wel voor.
Voor zover ik het begrepen heb: Een & werkt met een pointer naar de waarde. Deze pointer is ook een int. Dus bij int's geen het geen voordeel.
[ Bericht 0% gewijzigd door Toryu op 10-12-2013 21:44:51 ]
Wat betreft performance maakt het niets uit, daar zorgt de compiler wel voor.
Voor zover ik het begrepen heb: Een & werkt met een pointer naar de waarde. Deze pointer is ook een int. Dus bij int's geen het geen voordeel.
[ Bericht 0% gewijzigd door Toryu op 10-12-2013 21:44:51 ]
In principe maak je er dan een const reference van. Zo geef je aan dat je de waarde niet aan gaat passen en hoef je niet het hele object te kopieren. Bij fundamentele types heeft het maken van een referentie niet zoveel zin, en dus zou ik hier een const double gebruiken:quote:
Is het over het algemeen beter om optie 2 te gebruiken als je niet van plan bent Par.Xtion.sensorangle aan te passen?
| 1 | double const angle = Par.Xtion.SensorAngle; |
"Slechts diegene mag slopen die iets beters kan bouwen."
Oei, kun je me iets meer hier over uitleggen?quote:
[..]
In principe maak je er dan een const reference van. Zo geef je aan dat je de waarde niet aan gaat passen en hoef je niet het hele object te kopieren. Bij fundamentele types heeft het maken van een referentie niet zoveel zin, en dus zou ik hier een const double gebruiken:
[ code verwijderd ]
Ik volg even de link niet tussen const reference en bv const double.
Dus als ik angle niet aan ga passen in de code, en sensorangle al helemaal niet,
is het dan niet (eigenlijk) hetzelfde om const reference of const double te doen?
De meerwaarde van een referentie is dat je een object zonder te kopieren door kunt geven. Dit doe je (hopelijk) bij functies door `std::string const &` als parameter te hebben in plaats van gewoon een `std::string`. Dit gaat ten koste van een (onzichtbare) indirectie.quote:
[..]
Oei, kun je me iets meer hier over uitleggen?
Ik volg even de link niet tussen const reference en bv const double.
Dus als ik angle niet aan ga passen in de code, en sensorangle al helemaal niet,
is het dan niet (eigenlijk) hetzelfde om const reference of const double te doen?
Bij hele kleine objecten (zoals de fundamentele datatypes) is dit kopieren niet duur en meestal te prefereren boven de indirectie.
Qua functionaliteit is het precies hetzelfde: je hebt de waarde een naam gegeven en je kan 'et alleen lezen, niet veranderen.
"Slechts diegene mag slopen die iets beters kan bouwen."
+1 voor const na de type, daar hou ik van.quote:
[..]
In principe maak je er dan een const reference van. Zo geef je aan dat je de waarde niet aan gaat passen en hoef je niet het hele object te kopieren. Bij fundamentele types heeft het maken van een referentie niet zoveel zin, en dus zou ik hier een const double gebruiken:
[ code verwijderd ]
Bij fundamentele types gewoon by value doen, tenzij je een reference nodig hebt.
En bij andere types by const reference, tenzij je echt een copy wil. (of niet const)
Fungeert die const alleen als waarborg dat je ook echt nergens probeert de waarde aan te passen of is er nog een ander doel mee gemoeid?
De compiler kan die belofte gebruiken om de boel wat te optimaliseren.quote:
Fungeert die const alleen als waarborg dat je ook echt nergens probeert de waarde aan te passen of is er nog een ander doel mee gemoeid?
Bij een functiecall hoeft een const parameter bijvoorbeeld niet gecopieerd te worden.
More oneness, less categories
Open hearts, no strategies
Decisions based upon faith and not fear
People who live right now and right here
Open hearts, no strategies
Decisions based upon faith and not fear
People who live right now and right here
Zie ook http://www.parashift.com/c++-faq/const-correctness.html overigens, sowieso een aanrader van een site.
More oneness, less categories
Open hearts, no strategies
Decisions based upon faith and not fear
People who live right now and right here
Open hearts, no strategies
Decisions based upon faith and not fear
People who live right now and right here
Nja, als je gewoon fatsoenlijk je header files bouwt vind ik ze wel beter dan die packet troep in javaquote:
Op de een of andere manier gaat OOP mij moeilijker af in C++ dan in Java. De header-files vind ik zo'n zooitje.
Als ik een C+=2 zou maken zouden die header files er definitief uit mogen.
Beware of the Raping Zebra's
Je kunt ook gewoon alles in de header plempen. Maakt het niet echt overzichtelijker, behalve misschien wanneer je templates gebruikt. Compilen duurt alleen wel wat langer dan.
Dat kan in gewoon C++ ook prima. Als je het eens probeert in een iets groter project zie je ook meteen waarom ze beter wel gebruikt wordenquote:
Op de een of andere manier gaat OOP mij moeilijker af in C++ dan in Java. De header-files vind ik zo'n zooitje.
Als ik een C+=2 zou maken zouden die header files er definitief uit mogen.
More oneness, less categories
Open hearts, no strategies
Decisions based upon faith and not fear
People who live right now and right here
Open hearts, no strategies
Decisions based upon faith and not fear
People who live right now and right here
Ik weet dat het kan, maar dan wordt het snel een rotzooitje.quote:Op woensdag 11 december 2013 22:03 schreef trancethrust het volgende:
[..]
Dat kan in gewoon C++ ook prima. Als je het eens probeert in een iets groter project zie je ook meteen waarom ze beter wel gebruikt worden
Plus dat je methodes in een goede volgorde moeten staan.
Dus je vindt het met en zonder header-files een zooitje?quote:
[..]
Ik weet dat het kan, maar dan wordt het snel een rotzooitje.
Plus dat je methodes in een goede volgorde moeten staan.
More oneness, less categories
Open hearts, no strategies
Decisions based upon faith and not fear
People who live right now and right here
Open hearts, no strategies
Decisions based upon faith and not fear
People who live right now and right here
Eigenlijk wel.quote:Op woensdag 11 december 2013 22:38 schreef trancethrust het volgende:
[..]
Dus je vindt het met en zonder header-files een zooitje?
Sorry. Het is eerder dat ik zelf moeite heb structuur aan projecten aan te brengen terwijl ik dat bij andere talen wel heb. Maar dit komt ook omdat ik niet veel ervaring heb met C++ in vergelijking met die andere talen denk ik.
Ik heb nog een goed boek hier waar ik eens doorheen moet.
Java dwingt je idd echt om oop te doen. C++ totaal niet. Wat ik alleen wel echt schijt irritant vind aan Java is dat het geen pointers en references heeft. Ja ik weet ook waaromquote:Op woensdag 11 december 2013 22:41 schreef robin007bond het volgende:
[..]
Eigenlijk wel.
Sorry. Het is eerder dat ik zelf moeite heb structuur aan projecten aan te brengen terwijl ik dat bij andere talen wel heb. Maar dit komt ook omdat ik niet veel ervaring heb met C++ in vergelijking met die andere talen denk ik.
Ik heb nog een goed boek hier waar ik eens doorheen moet.
Goed dit was mijn beklag over Java weer
Beware of the Raping Zebra's
Alles in java is een pointer... behalve de fundamentele types (dacht ik?)quote:
[..]
Java dwingt je idd echt om oop te doen. C++ totaal niet. Wat ik alleen wel echt schijt irritant vind aan Java is dat het geen pointers en references heeft. Ja ik weet ook waarom
Goed dit was mijn beklag over Java weer
Onderwater wel iddquote:
[..]
Alles in java is een pointer... behalve de fundamentele types (dacht ik?)
Robert Moog died for our synths
Theoretisch wel ja, maar het werkt toch niet (altijd) zoals ik het zou verwachten (en in C++ zeker wel aan de praat zou krijgen)quote:
[..]
Alles in java is een pointer... behalve de fundamentele types (dacht ik?)
Ach project duurt nog maar een paar weekjes en dan ben ik er weer vanaf
Beware of the Raping Zebra's
Even een vraagje:
Ik heb een vector iterator en die laat m'n programma crashen als ik iets toevoeg aan die vector.
Maar dat doet ie alleen als ik bepaalde fields van het object gebruik:
Als ik dit doe dan werkt het gewoon
maar als ik dit probeer dan crashed ie
Ik vermoed dus dat ie de string niet zo leuk vind maar ik begrijp niet waarom, kan iemand mij uitleggen waarom het niet werkt?
Ik heb een vector iterator en die laat m'n programma crashen als ik iets toevoeg aan die vector.
Maar dat doet ie alleen als ik bepaalde fields van het object gebruik:
| 1 2 3 4 5 6 7 8 9 10 11 | class InputField{ std::string _DATA; unsigned short _X,_Y; // location unsigned short _DISPLAY_LENGTH; unsigned short _MAX_LENGTH; // 0 if no max length std::string _ONLY_ALLOWED; // empty if there are no restrictions for input bool _SELECTED; public: InputField(unsigned short x,unsigned short y,unsigned short display_length,bool selected=false,unsigned short max_length=0,std::string only_allowed=""); } |
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | class InputFieldController{ std::vector<InputField> _INPUTFIELDS; std::vector<InputField>::iterator _SELECTED; public: void InputFieldController::push_back(InputField push){ _INPUTFIELDS.push_back(push); if(push.getSelected()){ if(_INPUTFIELDS.size() == 1){ _SELECTED = _INPUTFIELDS.begin(); return; } _SELECTED->setSelected(false); _SELECTED = _INPUTFIELDS.end()-1; } } }; |
| 1 2 3 4 | myInputFields.push_back(InputField(12,1,35,true)); myInputFields.push_back(InputField(74,1,5)); myInputFields.push_back(InputField(29,2,50)); |
maar als ik dit probeer dan crashed ie
| 1 2 | myInputFields.push_back(InputField(10,1,70,true)); myInputFields.push_back(InputField(28,3,2,false,2,"0123456789")); |
Ik vermoed dus dat ie de string niet zo leuk vind maar ik begrijp niet waarom, kan iemand mij uitleggen waarom het niet werkt?
Beware of the Raping Zebra's
Heb je ook nog errors?quote:
Even een vraagje:
Ik heb een vector iterator en die laat m'n programma crashen als ik iets toevoeg aan die vector.
Maar dat doet ie alleen als ik bepaalde fields van het object gebruik:
[ code verwijderd ]
[ code verwijderd ]
Als ik dit doe dan werkt het gewoon
[ code verwijderd ]
maar als ik dit probeer dan crashed ie
[ code verwijderd ]
Ik vermoed dus dat ie de string niet zo leuk vind maar ik begrijp niet waarom, kan iemand mij uitleggen waarom het niet werkt?
Nee, alles compiled gewoon en dan APPCRASH. Dus dan krijg je zo'n popup ding van windows met dat het niet meer werkt.quote:
Ik denk dus dat die iterator niet valid meer is maar ik snap dus niet waarom hij bij de andere wel gewoon valid is
Beware of the Raping Zebra's
Ja dus wat is je error?quote:
[..]
Nee, alles compiled gewoon en dan APPCRASH. Dus dan krijg je zo'n popup ding van windows met dat het niet meer werkt.
Ik denk dus dat die iterator niet valid meer is maar ik snap dus niet waarom hij bij de andere wel gewoon valid is
Segmentation fault?
Maar om dat te krijgen moet je ook iets dereferecen, dus wat doe je daarna?
-edit-
In het vervolg moet je even een testcase schrijven voor ons
http://ideone.com/RPGgAC
valgrind
Je probleem is _selected->setSelected(false);quote:==19390== Invalid write of size 1
==19390== at 0x4009AF: InputField::setSelected(bool) (foo.cxx:10)
==19390== by 0x400A31: InputFieldController::push_back(InputField) (foo.cxx:25)
==19390== by 0x400927: main (foo.cxx:35)
==19390== Address 0x0 is not stack'd, malloc'd or (recently) free'd
_selected wijst nergens naar, dus segmentation fault
Dus wat je moet doen is eerst kijken of _selected ergens naar wijst.
Daarnaast als je een push_back doet hoeft je _selected ook al niet meer valid te zijn.
-edit- (nog geen reactie, dus ga ik maar even verder...)
Je kan hier beter geen iterator gebruiken, die dingen zijn om te iteraten niet om een element bij te houden in een vector.
Een index in de vector kan je wel bij houden, wordt het ook een stuk simpeler van.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | struct InputFieldController{ std::vector<InputField> _inputfields; unsigned _select; void push_back(InputField field) { if(field.getSelected()) { if(!_inputfields.empty()) _inputfields[_select].setSelected(false); } _inputfields.push_back(field); _select = _inputfields.size() - 1; } }; |
[ Bericht 12% gewijzigd door t4rt4rus op 29-04-2014 21:05:53 ]
hmm, wat ik al vermoedde dus die _SELECTED is niet valid maar die iterators kunnen dus invalid worden als je iets toevoegd?quote:
[..]
Ja dus wat is je error?
Segmentation fault?
Maar om dat te krijgen moet je ook iets dereferecen, dus wat doe je daarna?
-edit-
In het vervolg moet je even een testcase schrijven voor ons
http://ideone.com/RPGgAC
valgrind
[..]
Je probleem is _selected->setSelected(false);
_selected wijst nergens naar, dus segmentation fault
Dus wat je moet doen is eerst kijken of _selected ergens naar wijst.
Daarnaast als je een push_back doet hoeft je _selected ook al niet meer valid te zijn.
-edit- (nog geen reactie, dus ga ik maar even verder...)
Je kan hier beter geen iterator gebruiken, die dingen zijn om te iteraten niet om een element bij te houden in een vector.
Een index in de vector kan je wel bij houden, wordt het ook een stuk simpeler van.
[ code verwijderd ]
Dacht dat het eigenlijk gewoon soort van pointers waren met wat meer opties
Anyway bedankt denk dat ik idd dan maar een index bijhoud
Beware of the Raping Zebra's
Vectors doen intern een allocatie om een bepaald aantal elementen op te kunnen slaan. Wanneer je elementen toevoegt, worden deze in dat stukje geheugen opgeslagen. Naarmate je meer elementen toevoegen, zal dit geheugen vol raken. Op dat moment zal de vector een groter stuk geheugen alloceren en alle oude elementen daarheen verplaatsen. Op dat moment worden iterators ongeldig.
Ohja en misschien niet volledig hoofdletters gebruik in variabelen.quote:
[..]
hmm, wat ik al vermoedde dus die _SELECTED is niet valid maar die iterators kunnen dus invalid worden als je iets toevoegd?
Dacht dat het eigenlijk gewoon soort van pointers waren met wat meer opties
Anyway bedankt denk dat ik idd dan maar een index bijhoud
Lijkt net of je allemaal macro's gebruikt.
hmm, goed punt.quote:
[..]
Ohja en misschien niet volledig hoofdletters gebruik in variabelen.
Lijkt net of je allemaal macro's gebruikt.
Meestal doe ik dat om aan te geven wat in een class staat en wat niet maar met macro's doe je idd het zelfde...
Beware of the Raping Zebra's
Weet iemand hier hoe ik onder Windows (in console) een nieuwe screenbuffer kan maken waar std::cout << wel naar kan schrijven?
Ik heb nu een nieuwe buffer aangemaakt [daar kan ik ook naar schrijven via WriteConsoleOutput(...)]
Ook heb ik het volgende in m'n code:
Alleen std::cout pakt hij nu dus niet.
De data die ik in std::cout stop word wel ergens heen geschreven want als ik de ActiveBuffer weer naar de originele terug zet verschijnt de data wel ineens.
moet ik nog iets ander doen dan SetStdHandle(...) of is die gewoon kapot bij minGW?
Ik heb nu een nieuwe buffer aangemaakt [daar kan ik ook naar schrijven via WriteConsoleOutput(...)]
Ook heb ik het volgende in m'n code:
| 1 2 3 | SetStdHandle(STD_INPUT_HANDLE,hstdOut) SetStdHandle(STD_OUTPUT_HANDLE,hstdOut) SetStdHandle(STD_ERROR_HANDLE,hstdOut) |
De data die ik in std::cout stop word wel ergens heen geschreven want als ik de ActiveBuffer weer naar de originele terug zet verschijnt de data wel ineens.
moet ik nog iets ander doen dan SetStdHandle(...) of is die gewoon kapot bij minGW?
Beware of the Raping Zebra's
C++ kent geen Windows.
Ho dat is wat ze in ##c++ altijd zeggen tegen dit soort vragen.
Maar geen idee. Even op cppreference.com kijken.
Waarom doe je dit eigenlijk?
En wat doe je precies?
Ho dat is wat ze in ##c++ altijd zeggen tegen dit soort vragen.
Maar geen idee. Even op cppreference.com kijken.
Waarom doe je dit eigenlijk?
En wat doe je precies?
Op internet heb ik niks kunnen vinden er over.
Maar ik heb een soort van alert box gemaakt zodat ik meldingen kan geven maar daarna moet het oude scherm weer terug gezet worden (dus zonder de alert box er overheen getekend)
En ook om de buffer en grote van 80 bij 25 te geven zodat de scroll balk verdwijnt
Maar ik heb een soort van alert box gemaakt zodat ik meldingen kan geven maar daarna moet het oude scherm weer terug gezet worden (dus zonder de alert box er overheen getekend)
En ook om de buffer en grote van 80 bij 25 te geven zodat de scroll balk verdwijnt
Beware of the Raping Zebra's
|
|
