Archief - [C++] i++ vs ++i & oneindige loop

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Gurdt

Legacy Member
Mijn punt was enkel dat ++i efficienter is dan i++ (tenzij natuurlijk die optimalisatie).
En natuurlijk schrijf ik de postfix met een copy constructor, hoe wou jij dat doen dan?
Weet je wel wat het nut van een postfix-incrementatie is?? Dat wil zeggen dat je een KOPIE teruggeeft en de originele verhoogt/verlaagt (in geval van decrementeren).

Je mag van mij ook een volledig nieuwe klasse aanmaken en alle elementen overzetten (wat eigenlijk een copyconstructor doet).

Als jij een postfix-incrementatie wilt maken voor een klasse zonder een copyconstructor te gebruiken, moet je misschien je syntra-opleiding informatica maar eens opnieuw doen ;)

forloRn_

Legacy Member
Probeer wat op te letten. Aangezien je zelf de implementatie van de postfix schrijft, maak je zelf de kopie, en weet je op dat moment dus al dat je zult moeten betalen voor die kopie, maar dat is dus niet per definitie omdat het om een postfix gaat.

Hoe dan ook: als je van de schoolbanken afkomt en gaat werken, zal je wel merken dat het kiezen tussen i++ en ++i het minst van je zorgen is.

Curahee Q

Legacy Member
Nee dat denk ik ook wel maar de leerkracht heeft effectief in de les gezegd "De ervaren programmeurs zullen eerder ++i; schrijven ipv i++".

Altijd leuk om zo een dingen te weten. Knowledge is power!

Gurdt

Legacy Member
Ja forlorn, als je een beetje alle posts in deze thread leest, zie je dat ik ook zeg dat het praktisch onmerkbaar is, maar theoretisch is het gewoon beter, zoals curahee q zegt: het is iets waar ervaren programmeurs zich aan gaan houden, zo zijn er nog wel vuistregeltjes (die ik bijlange niet allemaal ken). ++i schrijven doet overigens niet meer pijn dan i++ schrijven :)

En ok forlorn, ik begrijp wat je wil zeggen, je bedoelt dat de postfix bij mij met ctor is geschreven, net omdat ik dat zelf gedaan heb. Maar ik daag je uit die postfix te herschrijven zonder een ctor te gebruiken.
Postfix wil zeggen dat je de klasse waarop je het doet gaat aanpassen, maar toch de oude waarde gaat teruggeven. Dat kan enkel en alleen als je de oude waarde bijhoudt.
Je kan dan een nieuwe instantie van die klasse maken en die handmatig invullen en aanpassen, maar dat is exact hetzelfde als de ctor gebruiken.
Je zal na enige ervaring later wel merken dat een postfix-functie altijd gebruik maakt van de copy constructor.

teh_NiHiLiM

Legacy Member
ff mijn 2cents over oneindige lussen;

beter dan while- of for-lus constructie, is simpele recursie :)

Curahee Q

Legacy Member
teh_NiHiLiM zei:
beter dan while- of for-lus constructie, is simpele recursie :)

Lijkt mij niet, maar niets weerhoud je ervan om het tegendeel te bewijzen ;)

[EDIT]
Alhoewel...

[EDIT2]
Het probleem (of mss niet zozeer een probleem) dat ik daarbij zie is dat als je bijvoorbeeld met wat variabelen zitten die elke keer worden aangepast, dan moet je die ook weer meegeven in je functie.

Code:
int i=0, j=0, k=1;

while(true) {
      i++;
      j+=2;

      cout << i << "*" << j << " = " << (i*j) << endl;
}

zou dan bij recursie worden

Code:
void recursie(int i, int j) {
      cout << i << "*" << j << " = " << (i*j) << endl;

      recursie(++i, j+=2);  
}

Recursie is wel korter maar wat als er weer meer parameters bijkomen...

Ook worden die parameters telkens gekopieerd bij een nieuwe functieaanroep waardoor (denk ik, don't shoot me if i'm wrong) het geheugen volloopt. Dan kan je inderdaad bij C++ met een reference werken

Code:
void recursie(int &i, int &j) {
      cout << i << "*" << j << " = " << (i*j) << endl;

      recursie(++i, j+=2);  
}

Maar bij java kan dit dan weer niet...

Cycloon

Legacy Member
teh_NiHiLiM zei:
ff mijn 2cents over oneindige lussen;

beter dan while- of for-lus constructie, is simpele recursie :)

:wtf:

Mijn sarcasmemeter weet het bij deze ook niet echt.

Tyfius

Legacy Member
teh_NiHiLiM zei:
ff mijn 2cents over oneindige lussen;

beter dan while- of for-lus constructie, is simpele recursie :)
Totaal niet he. Dat is elke keer een nieuwe function call die je doet. Dan is een while-loop iets performanter.

Cycloon

Legacy Member
Zelf als we performantie buiten beschouwing laten kan je met recursie nooit een oneindige lus maken omdat je recursiestack sowieso eindig is.

Gurdt

Legacy Member
Jongens :d dat is sarcastisch :d (althans, dat hoop ik toch)
Zoals cycloon hierboven zegt, kan dat zelfs niet ;)

teh_NiHiLiM

Legacy Member
ik ben eerder leek op het vlak van C,
dus ik weet ook niet zo goed hoe het daar zit;

maar uit puur computerwetenschappelijk standpunt...
diep vanbinnen in de C compiler wordt ook met recursie gewerkt voor die lussen te realiseren. nee? :p

Cycloon

Legacy Member
Nee, dat zijn gewoon sprongopdrachten die terugspringen naar de instructie waar de lus begon. Bij recursie wordt telkens een functie gestart, deze komt telkens bovenop de stack er bij. Die stack is er zodat je computer zou weten welke methodes nog moeten afgehandeld worden nadat een methode is afgelopen (immers, er kunnen nog opdrachten gebeuren na de oproepen van de recursie). Bij lussen heb je helemaal geen stack mechanisme nodig.

blackrabbit

Legacy Member
Tenzij je compiler staart-recursie optimaliseert, dan loopt je stack ook niet vol :)

Cycloon

Legacy Member
Ja maar dan is het geen recursie meer maar qua instructies gewoon een standaard while lus...
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan