[Java] Noob vraag: waarom while(true)?

[EddoH]

douweegbertje schreef op woensdag 17 juli 2013 @ 11:28:
[...]


Ok, dus stel je hebt een groot stuk code, waarin meerdere dingen moeten gebeuren.
Leg dan mij dan maar uit als je 10x while( true) er tussen hebt staan, dat je dit leesbaar vind?
En dan nog, 1 oogopslag? Nee, het enige wat jij weet is dat het letterlijk een infinite loop is, en met mijn voorbeeld weet je dat het een while loop is, totdat het geraden is.
IMO is een while ( true ) gewoon bad practise en zowat een verkapte 'hack'.

[...]

Verkapte hack? C'mon.
While(true) in combinatie met break kan je flow bijvoorbeeld een stuk logischer maken. Met een flag die je midden in de loop set moet je alweer een if-else statement toevoegen zodat je op dat moment de rest van de loop niet uitvoert.

Hangt allemaal uiteraard weer af van de situatie en context etc, maar vooraf diskwalificeren van while(true) is niet nodig.

[ Voor 7% gewijzigd door EddoH op 17-07-2013 11:37 ]

[Douweegbertje]

EddoH schreef op woensdag 17 juli 2013 @ 11:35:
[...]


Verkapte hack? C'mon.
While(true) in combinatie met break kan je flow bijvoorbeeld een stuk logischer maken. Met een flag die je midden in de loop set moet je alwaar een if-else statement toevoegen zodat je op dat moment de rest van de loop niet uitvoert.

Nja uiteindelijk zal het wel een persoonlijke voorkeur zijn in wat iemand gebruikt. Zo te lezen is het blijkbaar allemaal goed. Laat ik het dan zo zeggen dat ik zelf liever niet een while (true) ergens wil hebben.

En ja een verkapte hack. De "while ( EXPRESSION) " vraag in feite om een vergelijking die true moet zijn. Hier simpelweg "true" in gooien of "1==1" is imo gewoon een verkapte hack. Mja blijkbaar ben ik te praktisch/logisch om dingen letterlijk te volgen.

[Afvalzak]

Zelf gebruik ik alleen een while(true) als ik wil dat hij altijd blijft lopen (tenzij er echt een Exception gebeurt).

Ik vind het fijner om bij het lezen van de code al aan het begin van de loop te kunnen zien wanneer deze stopt. (kan ook met commentaar, maar met een goede variabelenaam werkt het imho het best

[freelh]

Oei, we zijn het niet eens. :-)
Kan de TS er zijn conclusie uit trekken?

En is het duidelijk hoe je guessp1 wordt geïnitialiseerd en vervolgens aangepast? Het toewijzen van een nul bij de initialisatie kan je zien als een gewoonte: meteen een getal toewijzen staat goed.
Mij werd wijsgemaakt dat dat het geheugengebruik en stabiliteit ten goede kwam... (Programmeren is niet mijn hoofdtaak van de dag).

[EddoH]

freelh schreef op woensdag 17 juli 2013 @ 11:49:
Oei, we zijn het niet eens. :-)
Kan de TS er zijn conclusie uit trekken?

En is het duidelijk hoe je guessp1 wordt geïnitialiseerd en vervolgens aangepast? Het toewijzen van een nul bij de initialisatie kan je zien als een gewoonte: meteen een getal toewijzen staat goed.
Mij werd wijsgemaakt dat dat het geheugengebruik en stabiliteit ten goede kwam... (Programmeren is niet mijn hoofdtaak van de dag).

'Wijsgemaakt' is inderdaad een goed woord hier...

[NMe]

Hatsieflatsie schreef op woensdag 17 juli 2013 @ 11:33:
[...]


[...]

Jongens, dit heb ik juist uit een lesboek, Head First Java. En daarin stond het niet uitgelegd. Wat moet je dan, als het zelfs in lesboeken niet uitgelegd is?

Nee, wat je dan moet is je boek daadwerkelijk lezen.

douweegbertje schreef op woensdag 17 juli 2013 @ 11:28:
[...]

Ok, dus stel je hebt een groot stuk code, waarin meerdere dingen moeten gebeuren.
Leg dan mij dan maar uit als je 10x while( true) er tussen hebt staan, dat je dit leesbaar vind?

Heb je mijn bericht hierboven gelezen? In games is één oneindige loop gangbaar. Afgezien van dat heb je behalve "normale" loops voor logica (bijvoorbeeld door het hele speelveld lopen) doorgaans geen loops nodig omdat je main loop al overal doorheen blijft itereren. Die 10x een while (true) ga je nooit tegenkomen behalve bij slechte programmeurs en uitzonderingsgevallen. Eén keer een while (true) is daarentegen vrij normaal en wordt veel gebruikt.

douweegbertje schreef op woensdag 17 juli 2013 @ 11:39:
[...]

En ja een verkapte hack. De "while ( EXPRESSION) " vraag in feite om een vergelijking die true moet zijn. Hier simpelweg "true" in gooien of "1==1" is imo gewoon een verkapte hack. Mja blijkbaar ben ik te praktisch/logisch om dingen letterlijk te volgen.

Onzin, een while vraagt niet om een vergelijking, een while vraagt om een expressie. En true is óók een expressie.

[ Voor 15% gewijzigd door NMe op 17-07-2013 11:56 ]

[Afvalzak]

freelh schreef op woensdag 17 juli 2013 @ 11:49:
Oei, we zijn het niet eens. :-)
Kan de TS er zijn conclusie uit trekken?

En is het duidelijk hoe je guessp1 wordt geïnitialiseerd en vervolgens aangepast? Het toewijzen van een nul bij de initialisatie kan je zien als een gewoonte: meteen een getal toewijzen staat goed.
Mij werd wijsgemaakt dat dat het geheugengebruik en stabiliteit ten goede kwam... (Programmeren is niet mijn hoofdtaak van de dag).

De reden dat je een object gelijk initialiseerd (dus een waarde toekennen bij aanmaken) is gewoon om er voor te zorgen dat als je hem gaat gebruiken er geen nullpointers komen als hij in de code nog niet is toegekend.
Eclipse geeft volgens mij tegenwoordig een fout als je dat probeert, maar niet alle IDE's (en zeker de wat oudere) deden dat niet.

[EddoH]

Afvalzak schreef op woensdag 17 juli 2013 @ 11:58:
[...]


De reden dat je een object gelijk initialiseerd (dus een waarde toekennen bij aanmaken) is gewoon om er voor te zorgen dat als je hem gaat gebruiken er geen nullpointers komen als hij in de code nog niet is toegekend.
Eclipse geeft volgens mij tegenwoordig een fout als je dat probeert, maar niet alle IDE's (en zeker de wat oudere) deden dat niet.

Met de opmerkign dat primitive type int default al naar 0 wordt geinitialiseerd en dus onnodig is om zelf te doen.

[Afvalzak]

EddoH schreef op woensdag 17 juli 2013 @ 12:02:
[...]


Met de opmerkign dat primitive type int default al naar 0 wordt geinitialiseerd en dus onnodig is om zelf te doen.

En nog meer:
http://docs.oracle.com/ja...tsandbolts/datatypes.html

[bwerg]

Afvalzak schreef op woensdag 17 juli 2013 @ 11:58:
[...]


De reden dat je een object gelijk initialiseerd (dus een waarde toekennen bij aanmaken) is gewoon om er voor te zorgen dat als je hem gaat gebruiken er geen nullpointers komen als hij in de code nog niet is toegekend.
Eclipse geeft volgens mij tegenwoordig een fout als je dat probeert, maar niet alle IDE's (en zeker de wat oudere) deden dat niet.

Een betekenisloze default-waarde gebruiken exceptions te ontwijken lijkt me juist een slechte gewoonte. Beter een nullpointer-exception krijgen (en dat bugfixen als nodig) dan een raar 'leeg' object gebruiken waar je code misschien gekke dingen mee gaat doen... Een betekenisloze waarde is eerder om foutmeldingen van je IDE/compiler weg te halen zoals je al zei.

Maar goed, met primitieve types heb je sowieso nooit null pointers dus het is voor dit voorbeeld helemaal niet relevant.

EddoH schreef op woensdag 17 juli 2013 @ 12:02:
[...]


Met de opmerkign dat primitive type int default al naar 0 wordt geinitialiseerd en dus onnodig is om zelf te doen.

Alleen als field, niet als lokale variabele.

[ Voor 12% gewijzigd door bwerg op 17-07-2013 12:49 ]

[Hydra]

bwerg schreef op woensdag 17 juli 2013 @ 12:47:
[...]

Een betekenisloze default-waarde gebruiken exceptions te ontwijken lijkt me juist een slechte gewoonte. Beter een nullpointer-exception krijgen (en dat bugfixen als nodig) dan een raar 'leeg' object gebruiken waar je code misschien gekke dingen mee gaat doen... Een betekenisloze waarde is eerder om foutmeldingen van je IDE/compiler weg te halen zoals je al zei.

Het is ook niet de bedoeling van die waarschuwing om je maar een 'placeholder' object aan te maken, het is de bedoeling om een dergelijke allocatie expliciet te maken. "Object myObject" leidt tot een myObject dat impliciet null is. Als het de bedoeling is dat deze pas verderop in je code gevuld wordt is het dus de bedoeling dat je er "Object myObject = null" van maakt. Zelfde geldt voor primitives; ook daar is het wel zo netjes expliciet aan te geven wat er mee moet gebeuren. Het is niet de bedoeling een "Object myObject = new Object();" te doen en die dan later alsnog weg te knikkeren want dan ben je gewoon resources aan het verspillen.

Hatsieflatsie schreef op woensdag 17 juli 2013 @ 11:33:
Jongens, dit heb ik juist uit een lesboek, Head First Java. En daarin stond het niet uitgelegd. Wat moet je dan, als het zelfs in lesboeken niet uitgelegd is?

Het probleem hier is dat het in general "not done" is om een oneindige lus te gebruiken en daar dan met een conditie uit te breken. Nu is een "game loop" een beetje een vreemde eend in de bijt omdat het een van de weinig plekken is waar een oneindige loop 'normaal' is. En deze twee dingen bijten elkaar een beetje. En dat levert een hoop discussies op zoals je ziet An sich is er niks mis met een oneindige loop, het probleem is alleen dat het vaak leidt tot misbruik, zoals:

code:

while(true) {
  i++
  if(i > 10) {
    break;
  }
}

En dat is natuurlijk enorm verkeerd

Ik vind het vreemd dat dit gebruikt wordt in een lesboek omdat je dat aan zou kunnen leren dat het 'normaal' is.

[ Voor 30% gewijzigd door Hydra op 17-07-2013 13:06 ]

[bwerg]

Hydra schreef op woensdag 17 juli 2013 @ 13:00:
Als het de bedoeling is dat deze pas verderop in je code gevuld wordt is het dus de bedoeling dat je er "Object myObject = null" van maakt.

Uiteraard, maar er stond een verhaaltje over het ontwijken van nullpointer-exceptions, wat inhoudt dat je rare objecten aan het aanmaken bent (dus geen null-references). En zoals je al zegt: dat is raar/inefficiënt/foutgevoelig.

Expliciete null-reference kan natuurlijk altijd. Als het niet hoeft vind ik het nog altijd mooier om het niet te doen trouwens, bijvoorbeeld zo:

Java:

Dier dier;
if (b)
    dier = new Aap();
else
    dier = new Olifant();
dier.eetBanaan();

Als je nu bijvoorbeeld de else vergeet krijg je een mooie foutmelding op regel 6 om je op de rare situatie te wijzen. Maar goed, in complexe situaties ga je de expliciete null soms toch nodig hebben.

[ Voor 15% gewijzigd door bwerg op 17-07-2013 13:11 ]

[Verwijderd]

Off topic: Je code ziet er niet uit. Een grote brei met tekens. Door het wat leesbaarder te maken zijn zulke vragen over het algemeen overbodig omdat je het geheel vrij snel kan overzien.

[Trokken]

Heb je wel eens gehoord van code indentation?

Als je met code indenteerd is het makkelijker te lezen.

[Gomez12]

douweegbertje schreef op woensdag 17 juli 2013 @ 11:39:
[...]
Nja uiteindelijk zal het wel een persoonlijke voorkeur zijn in wat iemand gebruikt. Zo te lezen is het blijkbaar allemaal goed. Laat ik het dan zo zeggen dat ik zelf liever niet een while (true) ergens wil hebben.

Hoe wil je het dan neerzetten als je in principe een oneindige loop wilt die moet stoppen als 1 van 50 condities true is?

Als het gaat om 1 conditie dan kan je idd net zo goed in de while zetten, maar heb je meerdere condities dan werk ik liever met breaks en while true.

[Amanoo]

Eeew, while(true) loops en breaks. Je wil altijd graag dat je code maar op één manier in een loop of kan komen en vooral op één plek er weer uit kan komen. Zo is mij dat op de universiteit geleerd, althans. Vroeger, toen we nog dichter bij de machine programmeerden dan nu met talen a la C++/Java waren GOTO's en Breaks nog heel normaal, maar de huidige talen zijn er juist voor gebouwd om de programmeur te helpen een minimale hoeveelheid spaghetti-code te laten maken, en het zo programmeerbaar te maken dat de programmeur altijd kan zeggen waar zijn loop stopt. Als je vervolgens een loop bouwt met tienduizend keer een if(conditie){break;} weet je dat niet. Een break lijkt al een beetje op een GOTO. Als je die ook nog gaat gebruiken krijg je al helemaal code vol spaghetti slierten en enorme knopen. Spaghetti vergroot de kans op fouten en maakt het lezen en onderhouden van code veel moeilijker. Mag je bij het onderhouden van de code alle breaks gaan opsporen, bijvoorbeeld.

Dit is overigens de programmeer-doctrine zoals die mij werd aangeleerd, en zoals die (AFAIK) over het algemeen als waar wordt gezien. Het is prima mogelijk om goede code te schrijven die vol staat met archaïsche zaken zoals break of GOTO, vroeger deed men niet anders, maar het wordt tegenwoordig niet meer aangeraden om zeer goede voorgenoemde redenen.

[ Voor 3% gewijzigd door Amanoo op 17-07-2013 14:42 ]

[Hydra]

Gomez12 schreef op woensdag 17 juli 2013 @ 14:28:
Hoe wil je het dan neerzetten als je in principe een oneindige loop wilt die moet stoppen als 1 van 50 condities true is?

Door die ifs een boolean te laten setten. Dat is 'de' manier als je het "single point of entry/exit" aanhangt. Vergeet niet dat dit soort regels in het leven geroepen zijn om spaghettirotzooi te voorkomen. Uiteindelijk is het doel om de code zo leesbaar mogelijk te maken. Met of zonder while(true)

[NMe]

Amanoo schreef op woensdag 17 juli 2013 @ 14:41:
Eeew, while(true) loops en breaks. Je wil altijd graag dat je code maar op één manier in een loop of kan komen en vooral op één plek er weer uit kan komen.

Dat is pertinent niet waar zoals ik al tot twee keer heb gezegd in dit topic. Dat jij iets in jouw line of work niet doet wil niet zeggen dat het per definitie fout is in elke branche. Het voorbeeld in dit topic is een spelletje, en juist voor spelletjes is dit dus wel gangbaar.

[HMS]

NMe schreef op woensdag 17 juli 2013 @ 14:54:
[...]

Dat is pertinent niet waar zoals ik al tot twee keer heb gezegd in dit topic. Dat jij iets in jouw line of work niet doet wil niet zeggen dat het per definitie fout is in elke branche. Het voorbeeld in dit topic is een spelletje, en juist voor spelletjes is dit dus wel gangbaar.

Amanoo schreef op woensdag 17 juli 2013 @ 14:41:
Zo is mij dat op de universiteit geleerd, althans.

There's your problem .

Misschien volgende keer even de thread doorlezen. Dat soort oude doctrines zijn vooral nog van belang bij C/C++ waarbij je dan mogelijk memory gaat leaken die in de loop worden gealloceerd. Bij Java met garbage collection is dat probleem een stuk minder, hoewel je natuurlijk wel moet opletten zodra je unmanaged objecten hebt (zoals file en netwerk streams, etc).

[Hatsieflatsie]

freelh schreef op woensdag 17 juli 2013 @ 11:49:
Oei, we zijn het niet eens. :-)
Kan de TS er zijn conclusie uit trekken?

En is het duidelijk hoe je guessp1 wordt geïnitialiseerd en vervolgens aangepast? Het toewijzen van een nul bij de initialisatie kan je zien als een gewoonte: meteen een getal toewijzen staat goed.
Mij werd wijsgemaakt dat dat het geheugengebruik en stabiliteit ten goede kwam... (Programmeren is niet mijn hoofdtaak van de dag).

Ik kan het nu wat beter begrijpen. Al vind ik het vrij vreemd, voor de true moet je toch eerst een situatie hebben waaruit je kunt vaststellen wat de conditie is voor de boolean.

En hoe guessp1 geïntaliseerd wordt, is mij ietsje duidelijker, maar nog steeds vaag.

NMe schreef op woensdag 17 juli 2013 @ 11:55:
[...]

Nee, wat je dan moet is je boek daadwerkelijk lezen.

Bovenstaande code van het raadspelletje heb ik pas uit de eerste hoofdstukken. Als ik je link zo lees, is het van bladzijde 111. Dus een heel eind verderop wordt het pas uitgelegd. .

[Hydra]

HMS schreef op woensdag 17 juli 2013 @ 15:00:
Misschien volgende keer even de thread doorlezen. Dat soort oude doctrines zijn vooral nog van belang bij C/C++ waarbij je dan mogelijk memory gaat leaken die in de loop worden gealloceerd. Bij Java met garbage collection is dat probleem een stuk minder, hoewel je natuurlijk wel moet opletten zodra je unmanaged objecten hebt (zoals file en netwerk streams, etc).

Ook in Java wil je niet onnodig meuk allocaten natuurlijk. Objecten maken / opruimen is relatief duur.

[HMS]

Hatsieflatsie schreef op woensdag 17 juli 2013 @ 15:12:
Ik kan het nu wat beter begrijpen. Al vind ik het vrij vreemd, voor de true moet je toch eerst een situatie hebben waaruit je kunt vaststellen wat de conditie is voor de boolean.

Op de plek van de expression (dus bijv: (a >0), (b != a), etc) komt het resultaat van de evaluatie daar van.
Dus om bij het voorbeeld te blijven:
als a = 1 en b = 1 dan evalueren ze zo:
a > 0 = true
b != a = false

Dus het resultaat van de expression levert een boolean op.

Dit kan je dan testen tegen de boolean 'true' waarmee je dus krijgt
true == true -> true
false == true -> false.

Maar als je de expression vervangt door de boolean 'true' is er dus niks te evalueren, dus wordt het ook:
true == true -> true

Maar dan altijd. Zo moeilijk is het niet.

Hydra schreef op woensdag 17 juli 2013 @ 15:15:
[...]


Ook in Java wil je niet onnodig meuk allocaten natuurlijk. Objecten maken / opruimen is relatief duur.

Dit klopt, maar ik zeg ook niet dat onnodig meuk allocaten in Java opeens wel moet / kan / gratis is. Alleen dat het op 1 punt beginnen en eindigen van loops en functies nog uit de C tijd stamt om gealloceerd geheugen weer vrij te kunnen geven . In ieder geval, daar zou ik die constructie nuttig vinden, in hedendaagse managed talen zie ik daar het nut een stuk minder van, zoals ik al had aangegeven .

[NMe]

Hatsieflatsie schreef op woensdag 17 juli 2013 @ 15:12:
[...]

Bovenstaande code van het raadspelletje heb ik pas uit de eerste hoofdstukken. Als ik je link zo lees, is het van bladzijde 111. Dus een heel eind verderop wordt het pas uitgelegd. .

Je snapte blijkbaar de while niet. Dan ga je bladeren in de index achterin en zoek je op waar de while besproken wordt. Je vindt dan vast die pagina wel. Lineair door een boek heen gaan werkt vast ook maar dan heeft het vast meer nut als je eerst leest en pas na afloop gaat programmeren.

[Hydra]

HMS schreef op woensdag 17 juli 2013 @ 15:24:
Dit klopt, maar ik zeg ook niet dat onnodig meuk allocaten in Java opeens wel moet / kan / gratis is. Alleen dat het op 1 punt beginnen en eindigen van loops en functies nog uit de C tijd stamt om gealloceerd geheugen weer vrij te kunnen geven . In ieder geval, daar zou ik die constructie nuttig vinden, in hedendaagse managed talen zie ik daar het nut een stuk minder van, zoals ik al had aangegeven .

Het was ook bedoeld als aanvulling, ben het met je eens

[Afvalzak]

Hatsieflatsie schreef op woensdag 17 juli 2013 @ 15:12:
[...]

Ik kan het nu wat beter begrijpen. Al vind ik het vrij vreemd, voor de true moet je toch eerst een situatie hebben waaruit je kunt vaststellen wat de conditie is voor de boolean.

En hoe guessp1 geïntaliseerd wordt, is mij ietsje duidelijker, maar nog steeds vaag.

Die while is heel simpel, de methode verwacht een boolean, en hoe hij er in komt maakt niet uit, of het nu handmatig "vast" gezet wordt of via een berekening.

Als je zelf een methode aanmaakt die een variabele verwacht hoef je ook niet een expressie te gebruiken om hem aan te roepen:

code:

public void myMethod(int value){
...
}

Kan zo:

code:

myMethod(2+2);

of

code:

myMethod(4);

of:

code:

int sum = 4;
myMethod(sum);

De code van het player object zou je in moeten zien om te kunnen zien wat dit doet, en het lijkt mij dat dat ook wel kan?:

code:

guessp1 = p1.number;

Maar eigenlijk staat hier niets anders dan:

code:

guessp1 =  (bijvoorbeeld) 100;

[ Voor 4% gewijzigd door Afvalzak op 17-07-2013 15:44 ]

[NMe]

Afvalzak schreef op woensdag 17 juli 2013 @ 15:42:
[...]

Die while is heel simpel, de methode language construct verwacht een boolean

Fixed that for you.

[Gomez12]

Hydra schreef op woensdag 17 juli 2013 @ 14:44:
[...]
Door die ifs een boolean te laten setten. Dat is 'de' manier als je het "single point of entry/exit" aanhangt. Vergeet niet dat dit soort regels in het leven geroepen zijn om spaghettirotzooi te voorkomen. Uiteindelijk is het doel om de code zo leesbaar mogelijk te maken. Met of zonder while(true)

Het enige probleem is dat je dan weer genoeg voorbeelden hebt waarbij dit soort stricte regels enkel maar meer spaghetti-code veroorzaken.

Als er net na het setten van de boolean een zware bewerking komt dan wil ik uit de loop voor de zware bewerking, ik wil niet vlak voor het uitvoeren van de zware bewerking checken of de boolean true/false is (want daar krijg je pas onbegrijpelijke code van). Ik wil er gewoon uit.

Het single-point of entry/exit is enkel noodzakelijk bij unmanaged code. Alles daarbuiten is het enkel maar meer balast (imho).

[Herko_ter_Horst]

Hatsieflatsie schreef op woensdag 17 juli 2013 @ 15:12:
[...]

Ik kan het nu wat beter begrijpen. Al vind ik het vrij vreemd, voor de true moet je toch eerst een situatie hebben waaruit je kunt vaststellen wat de conditie is voor de boolean.

Om dit te begrijpen, is het nodig dat je snapt wat expressies zijn en dat je snapt dat het while()-statement een boolean-expressie als argument verwacht.

Om met het eerste te beginnen: een expressie (in het algemeen) is "iets" dat een waarde oplevert. Bijvoorbeeld de rekenkundige expressie '1+1' levert de waarde '2' op. Je mag op elk moment een (deel-)expressie vervangen door de waarde die hij oplevert. Dus bijvoorbeeld: '(1+1)+2' mag je vervangen door '2+2', wat je weer mag vervangen door '4'.

Een boolean-expressie is een expressie die een boolean-waarde 'true' of 'false' oplevert. Dus bijvoorbeeld de expressie 'x > 1' levert de waarde 'true' op als de waarde van x groter is dan 1 en anders 'false'. De expressie '2 > 1' levert altijd de waarde 'true' op. De regels voor vervanging gaan ook hier op: '(2 > 1) && (3 > 4)' mag je vervangen door 'true && false', wat je weer mag vervangen door 'false'.

Het tweede stuk van de uitleg gaat over de syntax van Java: welke taal-constructies zijn valide als je Java-code schrijft. Het while-statment is zo'n taalconstructie. De syntax ervan is als volgt:
while(boolean-expression) {
statement(s)
}
Het while-statement kijkt of de waarde van de boolean-expressie gelijk is aan 'true'. Zo ja, dan worden de statements binnen de { } uitgevoerd, anders niet. Dit wordt herhaald nadat alle statements zijn uitgevoerd (tenzij er een statement tussen staat dat de normale flow onderbreekt, zoals een break, return of als er een exceptie wordt gegooid).

Op de plek van boolean-expression moet dus 'iets' komen te staan dat een boolean-waarde oplevert -- of dus de waarde zelf (aangezien je een expressie altijd mag vervangen door de waarde die die oplevert).

Dus 'while(2 > 1)' is dus gelijk aan 'while(true)'. 'true' is natuurlijk altijd gelijk aan 'true', dus wordt de code altijd uitgevoerd.

[ Voor 11% gewijzigd door Herko_ter_Horst op 17-07-2013 16:13 ]

[Afvalzak]

NMe schreef op woensdag 17 juli 2013 @ 15:44:
[...]

Fixed that for you.

Dit leek mij duidelijker voor een beginner

[Douweegbertje]

Gomez12 schreef op woensdag 17 juli 2013 @ 14:28:
[...]

Hoe wil je het dan neerzetten als je in principe een oneindige loop wilt die moet stoppen als 1 van 50 condities true is?

Als het gaat om 1 conditie dan kan je idd net zo goed in de while zetten, maar heb je meerdere condities dan werk ik liever met breaks en while true.

Ja even 2 punten;

1; blijkbaar is voor 'spelletjes' dus goed om een eindeloze loop er neer te gooien. Ik zelf heb dit nooit echt gemaakt en mijn echte focus is ook wat meer PHP, dus wellicht dat ik daarom ook zo liep/loop te bitchen over zo'n loop.

2; Waarom set je ten eerste 3x (per player) playerXGuessed = false en ga je dit IN je loop checken?
Ik zal wel het praktisch nut niet snappen, maar ik zou dan OF

code:

while (playerXGuessed == false || playerYGuessed == false

doen, of ergens iets neer zetten in de vorm van

code:

gameGuessed = false


while (gameGuessed == false)
{


if (guessp1 == targetNumber) { 
p1won = true;
//of gewoon
whoWon = "player1"
//en dan
gameGuessed = true 

}

Maar goed, ik zie hier veel ervarener mensen zeggen dat het in feite prima is om while (true ) te gebruiken en het dan te breaken. Dus ik hoef ook geen punt te maken, maar ik reageer even hoe ik het wellicht zou doen.

Daarbij gezien, zie ik de loop een soort van iteratie om 'het spel te spelen' , waarbij daarna de 'uitkomst' imo niet direct meer in de loop hoeft te staan. Sterker nog, voor mij zou het 10x overzichtelijker zijn als je de 'uitwerking' van de loop, NA de loop zou doen.
Maar dit is mijn mening, en wellicht moet ik dingen helemaal niet met elkaar vergelijken (nogmaals PHP'er hier).

[ Voor 13% gewijzigd door Douweegbertje op 17-07-2013 18:01 ]

[Hatsieflatsie]

Herko_ter_Horst schreef op woensdag 17 juli 2013 @ 16:08:
[...]

Herko ter Horst, je reactie verheldert een hoop. Enorm bedankt hiervoor, en HMS en Afvalzak uiteraard ook.

Jullie hebben mij iig weer stukje op weg geholpen. .

[ Voor 3% gewijzigd door Hatsieflatsie op 17-07-2013 18:02 ]

[Daos]

douweegbertje schreef op woensdag 17 juli 2013 @ 17:57:

code:

while (gameGuessed == false)

Ik doe zelf nooit vergelijkingen met '== true' of '== false'. '== true' kan weggegooid worden en '== false' wordt een not (!):

code:

while (!gameGuessed)

edit:
Ook geen '!= true' of '!= false'. Nu kan '!= false' weggegooid worden en '!= true' wordt een not (!).

[ Voor 17% gewijzigd door Daos op 17-07-2013 18:11 ]

[NMe]

douweegbertje schreef op woensdag 17 juli 2013 @ 17:57:
[...]

1; blijkbaar is voor 'spelletjes' dus goed om een eindeloze loop er neer te gooien. Ik zelf heb dit nooit echt gemaakt en mijn echte focus is ook wat meer PHP, dus wellicht dat ik daarom ook zo liep/loop te bitchen over zo'n loop.

Ook in PHP kan het zinnig zijn. Spelletjes hebben geen alleenrecht op een oneindige loop.

2; Waarom set je ten eerste 3x (per player) playerXGuessed = false en ga je dit IN je loop checken?

Omdat de loop die waarde ook kan muteren in dit geval.

code:

while (playerXGuessed == false || playerYGuessed == false

Niet handig als het spel later uitgebreid wordt met meerdere condities. Je wil bijvoorbeeld óók de loop afbreken als iemand op escape drukt (afsluiten) of wanneer je een pauze-knop implementeert.

code:

if (guessp1 == targetNumber) { 
p1won = true;

Java:

p1won = guessp1 == targetNumber;

Dit uiteraard even los van of het goed design is of niet, want variabelen met getalletjes erin zijn meestal een teken aan de wand.

Daos schreef op woensdag 17 juli 2013 @ 18:07:
[...]

Ik doe zelf nooit vergelijkingen met '== true' of '== false'. '== true' kan weggegooid worden en '== false' wordt een not (!):

code:

while (!gameGuessed)

Waar dan wel weer bij gezegd moet worden dat in PHP (niet relevant voor dit topic) de === en !== wel degelijk iets toe kunnen voegen.

[M.l.]

Het is een hele makkelijke manier om een "oneindige" loop te creeren. Als break word gecalled dan stopt de loop gelijk. Het is niet zo'n nette manier maar het zou misschien wat snelheidswinst kunnen geven. Je moet ergens natuurlijk wel kijken of er gebreaked moet worden maar als je dat binnen de loop doet zou je dat binnen bepaalde blocks code kunnen zetten die altijd worden gebruikt voor de loop moet worden gestopt. In dit geval is het echt niet nodig, er moet toch worden gewacht op user-input, niet echt netjes geprogrammeerd, wel effectief.

[farlane]

douweegbertje schreef op woensdag 17 juli 2013 @ 17:57:
1; blijkbaar is voor 'spelletjes' dus goed om een eindeloze loop er neer te gooien. Ik zelf heb dit nooit echt gemaakt en mijn echte focus is ook wat meer PHP, dus wellicht dat ik daarom ook zo liep/loop te bitchen over zo'n loop.

Een dergelijke loop heet een "superloop" en wordt in best wat situaties gebruikt. Probeer wat ruimdenkender te zijn, jouw situatie is niet hetzelfde als die van iedereen.

[ Voor 7% gewijzigd door farlane op 17-07-2013 23:30 ]

[Zoijar]

M.l. schreef op woensdag 17 juli 2013 @ 23:03:
maar het zou misschien wat snelheidswinst kunnen geven

Nee Het is een compare instructie (1 tik) en een conditional jump ipv een standaard jump, en die gaat gewoon door de branch prediction. Verder is het uiteraard nog geen miljoenste van je executietijd; dat merk je nooit.

Verder, ja, ach, een while true, als het goed leesbaar is. Enige waar je echt voor uit moet kijken is dit in je loop:

C++:

for (bool b : list) {
   if (b) break;
}

Want dat werkt niet. Een 'return' is misschien iets netter (dat werkt boven wel).

HMS schreef op woensdag 17 juli 2013 @ 15:00:
Dat soort oude doctrines zijn vooral nog van belang bij C/C++ waarbij je dan mogelijk memory gaat leaken die in de loop worden gealloceerd.

Hmm, je kan toch op elk (nouja, vaak) punt uit je functie gegooid worden door een exception, ofwel uit je eigen code, third party code of de standaard library. Moderne C++ code is daar tegen bestand en daar is het dus geen enkel probleem bij. Als het wel een probleem is dat je meer dan een exit point hebt is je code toch eigenlijk al niet robuust.

Wat ik me van de rationale achter die regel herinner is dat het voornamelijk ging om software testing en (automatische) formele verificatie.

[ Voor 36% gewijzigd door Zoijar op 18-07-2013 00:27 ]

[H!GHGuY]

Maasluip schreef op woensdag 17 juli 2013 @ 11:35:
[...]
Als er while (true) staat hoef je alleen maar te zoeken naar alle plekken waar een break staat. Als er while (!guessed) staat moet je alle plekken waar guessed gezet wordt gaan opzoeken. guessed kan ook gebruikt worden in een andere statements, dus niet alle keren dat je guessed vindt wordt het ook gezet.

Ik ga hier absoluut niet mee akkoord.

Als er while (true) staat, weet je bij doorlezen van de loop (en hij is best lang) helemaal niet wat de exit-conditie is en wat de loop doet. Je moet dan ook op zoek(!!!) naar alle break statements om dan alle bijhorende if-statements (en dat kunnen er veel zijn) te gaan interpreteren.

Als er staat while (!guessed), dan weet je direct dat de bedoeling van de loop is dat er iets geraden wordt en dat er meteen uit de loop gesprongen wordt als iets geraden is. Je exit-condities in de while () clause schrijven geeft iemand die de code leest dus _VEEL_ meer info over wat nou de bedoeling is.

Persoonlijk motto: jouw code heeft maar 2 stakeholders:
- de gebruiker ervan
- degene die na jou in de code wijzigingen moet aanbrengen (dit kan jijzelf over 2 jaar zijn...)

Voor de eerste moet de code correct zijn, voor de 2de moet hij leesbaar en onderhoudbaar zijn.
Zoals ik hierboven aantoon is while (!guessed) veel leesbaarder dan while (true) met dan een tiental breaks in de body.

Ik vind het ook cleaner om while (true) te gebruiken.

Om een break met een goto te vergelijken getuigt van weinig ervaring met BASIC. Met goto's maak je spaghetticode en kun je naar elk willekeurig stukje code springen. Met een break beëindig je alleen de loop.

break is ook een goto, net zoals continue dit is.
continue is wat mij betreft ook enkel in te zetten als guard clause direct in het begin van de loop:

C++:

while (i < 100) {
  if (complexfunction(objects[i])
  {
     log("error: XXX");
     continue; // goed
  }
  // andere
  // logica
  // hier
  if (something)
     continue; // fout
  // nog logica hier
}

Bemerk: dit zijn persoonlijk guidelines die ik aanhoud - er zullen altijd wel goede uitzonderingen zijn
In het geval van een game-loop, lijkt me een while (true) ook niet zo fout, deze springt er namelijk direct uit. Iedereen die in de code van een game kijkt zal meteen de game-loop herkennen.

[Gomez12]

H!GHGuY schreef op donderdag 18 juli 2013 @ 12:51:
[...]
Als er staat while (!guessed), dan weet je direct dat de bedoeling van de loop is dat er iets geraden wordt en dat er meteen uit de loop gesprongen wordt als iets geraden is.

Ehm, het bold gedeelte gebeurt niet hoor. De huidige loop-iteratie wordt eerst afgemaakt daarna wordt er pas uitgesprongen.

Dat is juist het grote verschil. Een break is direct, een while clausule maakt eerst de loop af.

[.oisyn]

H!GHGuY schreef op donderdag 18 juli 2013 @ 12:51:
break is ook een goto, net zoals continue dit is.

Als je break en continue een goto vindt dan volgt uit die redenatie dat een } aan het eind van de lus ook een goto is.

[bwerg]

En een simpele return. Of je moet inderdaad fan zijn van altijd op de laatste regel van een methode/functie returnen, wat compleet waardeloze code kan opleveren.

Oftewel: Het hangt toch echt gewoon van de situatie af, en als iets "meestal" zo is dan kan het voor iemand anders (die totaal andere programma's maakt) helemaal niet "meestal" zo zijn. Behalve dat een échte goto wel stom is natuurlijk, of gaat er nu ook iemand met een prachtig voorbeeld komen waarin een goto beter is dan alternatieven?

[Alain]

bwerg schreef op donderdag 18 juli 2013 @ 22:41:
Behalve dat een échte goto wel stom is natuurlijk, of gaat er nu ook iemand met een prachtig voorbeeld komen waarin een goto beter is dan alternatieven?

Als er geen betere alternatieven zijn misschien? Ik heb wel code gezien waarin geen alternatieven waren destijds (programma uit 1980). Ik moet wel zeggen dat die code sowieso praktisch onleesbaar was.

Met de huidige platformen zijn er volgens mij altijd betere alternatieven dan een goto.

[farlane]

Jeuj, een goto considered evil discussie!

PHP is echt een kuttaal.

[ Voor 25% gewijzigd door farlane op 18-07-2013 23:32 ]

[Gomez12]

bwerg schreef op donderdag 18 juli 2013 @ 22:41:
Oftewel: Het hangt toch echt gewoon van de situatie af, en als iets "meestal" zo is dan kan het voor iemand anders (die totaal andere programma's maakt) helemaal niet "meestal" zo zijn. Behalve dat een échte goto wel stom is natuurlijk, of gaat er nu ook iemand met een prachtig voorbeeld komen waarin een goto beter is dan alternatieven?

Je begon zo goed...

Laat ik het zo zeggen, er is een reden dat goto nog steeds bestaat in de huidige talen... En die reden is geen spaghetti-code.

Je moet het altijd zo zien : Elke regel (qua programmeren) die je ooit ergens geleerd hebt wordt ergens anders weer met een goede reden gebroken. OO-programmeren is heel leuk maar probeer dat niet op een embedded device met 32k geheugen etc. etc.

AlainS schreef op donderdag 18 juli 2013 @ 23:30:
[...]
Met de huidige platformen zijn er volgens mij altijd betere alternatieven dan een goto.

Yep, programmeertaal ontwerpers gooien altijd oude legacy dingen erin die altijd betere alternatieven hebben...
Er zijn wellicht (bijna) altijd betere alternatieven als je zit te programmeren voor een dual-core x86 machine met 1 Gb geheugen, maar dat beslaat bij lange na niet het totale programmeerveld.
Wil jij echte snelheid dan verslaat niets een simpele goto

[deadinspace]

bwerg schreef op donderdag 18 juli 2013 @ 22:41:
Behalve dat een échte goto wel stom is natuurlijk, of gaat er nu ook iemand met een prachtig voorbeeld komen waarin een goto beter is dan alternatieven?

Uiteraard, die "Goto is de duivel"-sentimenten zijn ook onzin. Er zijn best situaties waarin goto acceptabel of zelfs de beste oplossing is. De bekendste is wel single-out-met-cleanup in C:

C:

char *blaat( char *file )
{
    char *s, *t, *value;
    int fd;

    s = malloc( 1024 );
    if( !s )
        return NULL;

    fd = open( file, O_RDONLY );
    if( fd < 0 )
    {
        free( s );
        return NULL;
    }

    t = get_something( file, fd );
    if( !t )
    {
        free( s );
        close( fd );
        return NULL;
    }

    value = actually_do_something( s, t, fd );
    free( s );
    close( fd );
    close( t );
    return value;
}

versus

C:

char *blaat( char *file )
{
    char *s = NULL, *t = NULL, *value = NULL;
    int fd = -1;

    s = malloc( 1024 );
    if( !s )
        goto out;

    fd = open( file, O_RDONLY );
    if( fd < 0 )
        goto out;

    t = get_something( file, fd );
    if( !t )
        goto out;

    value = actually_do_something( s, t, fd );

out:
    free( s );
    close( fd );
    free( t );
    return value;
}

Waarbij de tweede variant korter en naar mijn mening leesbaarder is. Heeft de functie meer dan 3 error-checks, dan wordt het verschil natuurlijk alleen maar groter.

Dit is natuurlijk minder van toepassing voor modernere talen vanwege bv exceptions en garbage collection (en de context was natuurlijk Java), maar dat neemt niet weg dat dit een voorbeeld van prima goto-gebruik is

Ook heb ik argumenten gehoord voor goto in het implementeren van een finite state machine, en daar kan ik me ook wel in vinden, al ben ik dat nog niet in het wild tegen gekomen en heb ik dat zelf nooit gebruikt.

[Hatsieflatsie]

Tussen deze bedrijven door.. 1 kleine vraag.

Als je refereert naar een object... Dan gebruik je de volgende code, bijvoorbeeld:

Java:

Dog d = new Dog();
d.bark();

Dan vraag ik mij af, waarom daar 'new' staat?

Is het niet handiger zo te doen:

Java:

Dog = d;
d.bark();

Waarom is er voor gekozen om Dog en new toe te voegen in de Java syntax?

[HMS]

Omdat je een nieuwe instantie van de klasse Dog aanmaakt. Maar dit staat zeker weten ook in je boek.

Waarschijnlijk is de syntax zo omdat het in C++ en de meeste OO talen de gebruikelijke constructie is.

edit:
Simpel gezegd: de variable d bevat een nieuwe instantie van de klasse Dog.
Iets moeilijker: de variable d wijst naar het geheugenadres waar een nieuwe instantie van de klasse Dog is aangemaakt.

[ Voor 33% gewijzigd door HMS op 19-07-2013 00:27 ]

[Grijze Vos]

Omdat je ook:

code:

Dog d = new DanishDog();

kan doen.

Je moet declareren wat het type en de naam van de variabele is (dat staat aan de linkerzijde van het = teken.) Je zou nog ervoor kunnen kiezen om eventueel new weg te laten in je taal ontwerp, maar het maakt de parser wat eenvoudiger en sneller als je die wel hebt.

[Russel88]

Een discussie van 3 pagina's over een while loop.

Modbreak: Bedankt voor deze zeer nuttige bijdrage!

[ Voor 36% gewijzigd door NMe op 19-07-2013 10:23 ]

[kenneth]

En natuurlijk:

Java:

Dog d = new DanishDog("Fluffy", "brown");

[NMe]

Hatsieflatsie schreef op vrijdag 19 juli 2013 @ 00:22:
Tussen deze bedrijven door.. 1 kleine vraag.

Als je refereert naar een object... Dan gebruik je de volgende code, bijvoorbeeld:

Java:

Dog d = new Dog();
d.bark();

Dan vraag ik mij af, waarom daar 'new' staat?

Is het niet handiger zo te doen:

Java:

Dog = d;
d.bark();

Waarom is er voor gekozen om Dog en new toe te voegen in de Java syntax?

Ten eerste is dit niet gerelateerd aan dit topic en ten tweede is dit prima te vinden op het internet. Doe eens niet elke vraag die in je opkomt hier dumpen.

[Caelorum]

Afgezien van wat NMe zegt zou je voor die vraag even je boek moeten raadplegen over inheritance en polymorphism.

[H!GHGuY]

Gomez12 schreef op donderdag 18 juli 2013 @ 15:32:
[...]

Ehm, het bold gedeelte gebeurt niet hoor. De huidige loop-iteratie wordt eerst afgemaakt daarna wordt er pas uitgesprongen.

Dat is juist het grote verschil. Een break is direct, een while clausule maakt eerst de loop af.

Juist. De volgende vraag is of de structuur van de code binnen de while niet beter kan zodat je niet midden in de loop moet breaken.

Een computer heeft allemaal geen probleem met goto, break en continue. Het zijn de programmeurs die het probleem hebben. Als je halverwege een loop break't dan is dat mijns inziens enkel te rechtvaardigen als het in een oogopslag duidelijk is wat de state is van de complete context van die loop.

Daarom dat een continue als guard clause in het begin van de while loop voor mij best kan. Er is namelijk nog geen code uitgevoerd binnen de body van de while loop en de staat is dus net dezelfde als ze was voor de while loop (of na de vorige iteratie). Als je echter halverwege de loop een break of continue doet dan is het voor mij (die de code leest en misschien ook later aanpast) een stuk moeilijker om na te gaan wat de context is als je de loop verlaat en dus ook een stuk moeilijker om bij aanpassingen ervoor te zorgen dat die context nog steeds correct is.
Nogmaals, dit zijn guidelines. Er zijn zeker voorbeelden te bedenken die wel lekker lezen, bvb:

C++:

Obj* nextObject = NULL;
for (size_t i = 0; i < numItems; ++i)
{
  if (complexe_conditie_hier(object[i]))
  {
     nextObject = &object[i]
     break;
  }
  discard(object[i]);
}
return nextObject;

.oisyn schreef op donderdag 18 juli 2013 @ 16:16:
[...]

Als je break en continue een goto vindt dan volgt uit die redenatie dat een } aan het eind van de lus ook een goto is.

Misschien wel.

Expressieve, leesbare en onderhoudbare code heeft een belangrijke eigenschap: onbelangrijke dingen vallen niet op en moeten ook zo weinig mogelijk opvallen, belangrijke dingen vallen wel op en moeten ook zoveel mogelijk opvallen. Met andere woorden, bij onbelangrijke dingen voldoet alles aan de verwachting, en belangrijke/speciale dingen springen er meteen uit.

Daarom dus dat een while (true) als gameloop OK is. Dit is verwacht en normaal. Als de hele code er echter vol mee staat heb je gewoon een probleem met onderhoudbaarheid.

Dit is hetzelfde met (true) Hungarian notation. Het valt op als je:

C++:

utfData = ascString

doet, maar het is volstrekt normaal en onbelangrijk als je

C++:

utfData = to_utf(ascString);

doet. Allemaal het patroon van de verwachting.

[drm]

Ben ik de enige die dit juist in een do/while zou zetten? De eerste iteratie is altijd nodig, en die bepaalt het al dan niet nodig zijn van elke volgende iteratie. In mijn ervaring is moeilijk doen in een while best vaak een gevolg van het mijden van een do/while.

[NMe]

In dit specifieke geval is een do...while inderdaad beter, mits goed geïmplementeerd.

Wat betreft het mijden van do..while weet ik het niet zo. Ik heb niet het idee dat het vermeden wordt maar eerder het idee dat mensen zich niet altijd even goed realiseren dat het kan.

[ZpAz]

deadinspace schreef op donderdag 18 juli 2013 @ 23:43:
[...]

Uiteraard, die "Goto is de duivel"-sentimenten zijn ook onzin. Er zijn best situaties waarin goto acceptabel of zelfs de beste oplossing is. De bekendste is wel single-out-met-cleanup in C:

Je zou het ook zo kunnen oplossen.

C:

char *blaat( char *file ) 
{ 
    char *s = NULL, *t = NULL, *value = NULL; 
    int fd = -1; 

    char *value = NULL;
    
    s = malloc( 1024 ); 
    if( s ) 
    {
        fd = open( file, O_RDONLY ); 
        if( fd > 0 ) 
        {
            t = get_something( file, fd ); 
            if( t )         
            {
                value = actually_do_something( s, t, fd ); 
            }
        }
    }

    free( s ); 
    close( fd ); 
    free( t ); 
    
    return value;     
}

Geen 'c-er' hier zou een foutje in kunnen zitten, maar het gaat om het idee. Ik houd niet bepaald van de algemeen "geacepteerde trend" qua variabelenamen e.d daar.

[ Voor 3% gewijzigd door ZpAz op 19-07-2013 21:05 ]

[Glorificationer426]

Uiteraard kun je dat zo doen, maar het lijkt me overbodig complex qua nesting...

[Sendy]

Het probleem is dat je in de toekomst na actually_do_something() nog iets extra's moet doen. Dat extra blijkt dan niet helemaal gerelateerd aan wat er al in actually_do_something() gedaan wordt. Dus maak je een nieuwe functie en voeg je een extra nestingniveau toe en ben je bedroefd.

[Onbekend]

Dit is een interessante discussie geworden, en zelf ben ik ook gedeeltelijk van gedachte veranderd naar mate ik het topic verder las.

Hoofdzakelijk wil ik nooit op een event-based systeem een while(true) hebben. Ik vind zelf namelijk dat er altijd een conditie zijn waardoor hij uit de loop kan komen. Als ik er echt niet aan ontkom, gebruik ik een timeout o.i.d. zodat een programma nooit oneindig lang zal door lopen. Maar dan heb ik dit in een aparte thread staan, die door een andere thread gecontroleerd wordt.

Ook in een microcontroller heb ik vaak alleen een mainloop die nauwelijks iets doet. Alles gaat via interrupts en "states" waar die zich in bevindt. (Net zoals in een FPGA.)

Tijdens een while-loop er uit springen is vaak alleen tijdsbesparend en nodig als je een zoekalgoritme hebt die moet stoppen als die iets heeft gevonden. Je moet dan wel opletten dat je het geheugen van de variablen weer vrijgeeft, want geheugenlekjes zijn daarmee snel gemaakt.

[Jegorex]

Als while(true) te onduidelijk is kun je altijd nog kiezen voor while(true==true) of while(true!=false)

[NMe]

Onbekend schreef op vrijdag 19 juli 2013 @ 23:29:
Hoofdzakelijk wil ik nooit op een event-based systeem een while(true) hebben. Ik vind zelf namelijk dat er altijd een conditie zijn waardoor hij uit de loop kan komen.

En wat dan als er 10 verschillende condities zijn op basis waarvan een complexe loop kan afbreken? Of 20? Dan kun je het wel op gaan vangen in één variabele maar als die exit-condities niets met elkaar gemeen hebben kun je die variabele alleen een naam geven die lijkt op "breakLoop". De vraag is of while (!breakLoop) met tig keer breakLoop = true; in verschillende condities nou zo veel handiger is dan het gebruiken van de tools die een taal uit zichzelf biedt. Ik zou daar net zo makkelijk voor een while (true) en break-combinatie gaan.

[H!GHGuY]

NMe schreef op zaterdag 20 juli 2013 @ 01:15:
[...]

En wat dan als er 10 verschillende condities zijn op basis waarvan een complexe loop kan afbreken? Of 20? Dan kun je het wel op gaan vangen in één variabele maar als die exit-condities niets met elkaar gemeen hebben kun je die variabele alleen een naam geven die lijkt op "breakLoop". De vraag is of while (!breakLoop) met tig keer breakLoop = true; in verschillende condities nou zo veel handiger is dan het gebruiken van de tools die een taal uit zichzelf biedt. Ik zou daar net zo makkelijk voor een while (true) en break-combinatie gaan.

Sure, kan gebeuren. En zoals ik hierboven al zei: speciale gevallen moeten eruit springen. Zo'n loop is duidelijk een speciaal geval (veel exit-condities, complexe logica). Persoonlijk zou ik dan verwachten dat:
- er goed gedocumenteerd is wat de loop doet en wat de exit-condities zijn
- dat zoveel mogelijk code uitgefactored is in functies met duidelijke naam zodat ze de leesbaarheid van de loop niet teveel vervuilt. Bovendien zie je op die manier duidelijk welk stuk code welke data nodig heeft en kan aanpassen (const of niet).
- dat er in de functie zelf rond die loop zo weinig mogelijk code staat (maw de loop zelf is zo goed als kan uitgefactored) en dat die functie zelf ook een goede naam heeft.

Op die manier maak je zelfs moeilijke code zo goed leesbaar als mogelijk.

[Zoijar]

ZpAz schreef op vrijdag 19 juli 2013 @ 21:03:
Je zou het ook zo kunnen oplossen.

Veel netter inderdaad imho.

Je kan het nog wat compacter maken op de standaard C manier.

C:

char *blaat( char *file ) 
{ 
    char *s = NULL, *t = NULL, *value = NULL; 
    int fd = -1; 
    
    if( 
        (s = malloc(1024)) && 
        (fd = open(file, O_RDONLY)) && 
        (t = getsomething(file, fd )) 
    ) {
        value = actually_do_something( s, t, fd ); 
    }

    free( s ); 
    close( fd ); 
    free( t ); 
    
    return value;     
}

---

Half unix en dus de wereld zit trouwens vol met while(true) loops

[ Voor 6% gewijzigd door Zoijar op 20-07-2013 10:11 ]

[H!GHGuY]

Zoijar schreef op zaterdag 20 juli 2013 @ 10:04:
[...]

Veel netter inderdaad imho.

Je kan het nog wat compacter maken op de standaard C manier.

C:

char *blaat( char *file ) 
{ 
    char *s = NULL, *t = NULL, *value = NULL; 
    int fd = -1; 
    
    if( 
        (s = malloc(1024)) && 
        (fd = open(file, O_RDONLY)) && 
        (t = getsomething(file, fd )) 
    ) {
        value = actually_do_something( s, t, fd ); 
    }

    free( s ); 
    close( fd ); 
    free( t ); 
    
    return value;     
}

---

Half unix en dus de wereld zit trouwens vol met while(true) loops

Helaas is 0 een valid file descriptor en kan open() ook -1 returnen als error, dus er moeten nog enkele kleine aanpassingen gedaan worden voor dit correct is.

[ Voor 5% gewijzigd door H!GHGuY op 20-07-2013 11:47 ]

[Zoijar]

H!GHGuY schreef op zaterdag 20 juli 2013 @ 11:46:
[...]


Helaas is 0 een valid file descriptor en kan open() ook -1 returnen als error, dus er moeten nog enkele kleine aanpassingen gedaan worden voor dit correct is.

>= 0

...

Compile je ook altijd met -pedantic ?

[ Voor 6% gewijzigd door Zoijar op 20-07-2013 12:11 ]

[Daos]

NMe schreef op vrijdag 19 juli 2013 @ 17:43:
In dit specifieke geval is een do...while inderdaad beter, mits goed geïmplementeerd.

Wat betreft het mijden van do..while weet ik het niet zo. Ik heb niet het idee dat het vermeden wordt maar eerder het idee dat mensen zich niet altijd even goed realiseren dat het kan.

In sommige boeken wordt de do...while niet behandeld. Het staat bijvoorbeeld niet in de eerste editie van "Java by Dissection" die wij op de universiteit gebruikten. In "Head First C#" (andere taal; gaat om het idee) komt de do...while ook niet voor.

[Zoijar]

Daos schreef op zaterdag 20 juli 2013 @ 18:08:
in de eerste editie van "Java by Dissection" die wij op de universiteit gebruikten. In "Head First C#" (andere taal; gaat om het idee) komt de do...while ook niet voor.

Typisch geval van http://www.watbenjedan.com/

[Caelorum]

Ik vind de Head First serie persoonlijk ook niet zo geweldig qua inhoud. Wellicht dat mensen die plaatjes enzo leuk vinden, maar het is iig duidelijk dat er daardoor minder aandacht aan de daadwerkelijke inhoud wordt besteed.

[Daos]

Dit topic gaat over "Head First Java". Of het een slecht boek is kan ik niet beoordelen; ik heb hem niet gelezen.

Ik heb wel even gespiekt daarin nav dit topic en de do-while wordt wel genoemd op pagina 11:

Java has three standard looping construcs: while, do-while, and for.

, maar verder in het boek zie ik hem niet staan.

Nog iets vreemds: break wordt wel behandeld, maar continue niet.

[Verwijderd]

Daos schreef op zaterdag 20 juli 2013 @ 23:34:
Dit topic gaat over "Head First Java". Of het een slecht boek is kan ik niet beoordelen; ik heb hem niet gelezen.

Ik ben op dit moment met dit boek bezig, het wordt door veel tweakers op de boekenlijst aanbevolen.
Of dit boek een goed of slecht boek is laat ik in het midden, maar als je het boek beoordeeld op deze oefening wil ik je even wijzen op deze passage uit hoofdstuk 2 blz 38 (die van de oefening)

"In chapter 6 we look at using a class with main() method to start the ball rolling on a real java application. As a sneak preview, though of how a real java application might behave here's a little example. Because we're still at the early stages of learning java, we're working with a small toolkit, so you'll find this program a little clunky and inefficient. You might want to think about what you could do to improve it, and in later chapters that's exactly what we'll do.Don't worry if some of the code is confusing: the key point is that objects talk to objects."

Dit boek werk met een aparte leerstijl, waarbij je veel zelf moet nadenken over het hoe en waarom. De code die geleverd word bevat meestal (in deze hoofstukken) express (kleine) fouten/eigenaardigheden om je aan het denken te zetten.

[Herko_ter_Horst]

Voor een eerste kennismaking met een programmeertaal is het helemaal niet nodig om alle facetten van die taal te behandelen. for-, while- and do-loops zijn onderling uitwisselbaar. Ja, soms is de één wat handiger en leesbaarder en soms de ander, maar een introductieboek afschrijven omdat het de do-loop niet behandeld, gaat veel te ver.

[ThomasG]

NMe schreef op zaterdag 20 juli 2013 @ 01:15:
[...]

En wat dan als er 10 verschillende condities zijn op basis waarvan een complexe loop kan afbreken? Of 20? Dan kun je het wel op gaan vangen in één variabele maar als die exit-condities niets met elkaar gemeen hebben kun je die variabele alleen een naam geven die lijkt op "breakLoop". De vraag is of while (!breakLoop) met tig keer breakLoop = true; in verschillende condities nou zo veel handiger is dan het gebruiken van de tools die een taal uit zichzelf biedt. Ik zou daar net zo makkelijk voor een while (true) en break-combinatie gaan.

Totdat je bij talen als MISRA C komt, waarbij zaken als continue, continue en while (true) uit den boze zijn.

[Daos]

Herko_ter_Horst schreef op zondag 21 juli 2013 @ 10:05:
een introductieboek afschrijven omdat het de do-loop niet behandeld, gaat veel te ver.

Wie doet dat dan? Ik merkte alleen op dat het wel eens overgeslagen wordt in boeken.

Net als continue. Ik gebruik continue regelmatig. Neem bijvoorbeeld mijn Sudoku Solver uit [JAVA] Code verkorten naar methode:

C#:

for (int r = 0; r < size; r++)
{
    for (int c = 0; c < size; c++)
    {
        if (number[r, c] > 0)
        {
            // process empty cells only; this one is not empty
            continue;
        }
        
        // process empty cell...

[NMe]

ThomasG schreef op zondag 21 juli 2013 @ 11:51:
[...]
Totdat je bij talen als MISRA C komt, waarbij zaken als continue, continue en while (true) uit den boze zijn.

MISRA C is voor zover ik kan vinden gaan taal maar een richtlijn voor het schrijven van C-code in een heel specifieke branche. Daar is het om te beginnen al veel makkelijker om een probleemdomein te definiëren en dus om spul als while (true) af te schieten. Dat gezegd hebbende vind ik het redelijk debiel om onderdelen van een taal af te schieten omdat een of andere commissie ooit heeft verzonnen dat ze altijd slecht zijn. Ik heb hierboven legio voorbeelden genoemd van situaties waar het handig kan zijn om een oneindige loop te maken die je al dan niet kan breaken. Continue is afhankelijk van de specifieke loop ook best handig. Zelfs voor goto zullen er wel toepassingen mogelijk zijn die handiger zijn dan het "nette" alternatief.

[Daos]

ThomasG schreef op zondag 21 juli 2013 @ 11:51:
[...]
Totdat je bij talen als MISRA C komt, waarbij zaken als continue, continue en while (true) uit den boze zijn.

Geen goto; geen continue; max 1 break per loop; single exit point bij functies; altijd een else na "if ... else if ..."; geen unions; geen atoi, atof, atol; geen stdio; geen dynamic heap memory allocation (malloc ??); geen recursie

Dat while(true) verboden is kon ik trouwens niet vinden.

[Infant]

C:

while(1){
    //code
}

for (;;){
    //code
}

foo:
    //code
goto foo;

Het is gewoon allemaal hetzelfde, en zou moeten compilen naar een type jump statement (afhankelijk van hoeveel zooi er in de loop staat, en op welk platform je bezig bent).

Bijv: gcc op een x86 compiled een loop als:

C:

while(1){
   a++;
}

Naar:

GAS:

L2:
    incl    12(%esp)
    jmp L2

Persoonlijk vind ik de while(1){} constructie het netst.

[Soultaker]

Ik weet niet hoe je daar bij komt, maar ik heb GCC nog nooit een inc instructie zien genereren, en een lus als deze zal de increment-operatie sowieso óf worden weggeoptimaliseerd, of expliciet via een load/store sequence worden uitgevoerd (wanneer a volatile gedeclareerd is, of wanneer er zonder optimalisaties gecompileerd wordt).

edit:
Met -Os kun je in principe wel inc instructies krijgen, maar dan nog wordt de operatie weggeoptimaliseerd.

[ Voor 16% gewijzigd door Soultaker op 21-07-2013 17:23 ]

[Daos]

Ik krijg standaard:

code:

L2:
    addl    $1, 12(%esp)
    jmp L2

en met -O :

code:

L2:
    jmp L2

[farlane]

Daos schreef op zondag 21 juli 2013 @ 15:17:
Geen goto; geen continue; max 1 break per loop; single exit point bij functies; altijd een else na "if ... else if ..."; geen unions; geen atoi, atof, atol; geen stdio; geen dynamic heap memory allocation (malloc ??); geen recursie

Dat while(true) verboden is kon ik trouwens niet vinden.

Dat while( true ) "verboden" is kan ik me niet voorstellen, helemaal niet omdat het in vrijwel elk embedded programma voorkomt.

Misra C heeft een aantal nuttige regels ( die je toch al zou toepassen als je defensief programmeert ) maar ook een aantal kortzichtige waarvan je er nu een aantal opnoemt. ( Behalve het gebruik van malloc, dat ligt in een embedded platform wat lastig )

[H!GHGuY]

Zoijar schreef op zaterdag 20 juli 2013 @ 12:09:
[...]
Compile je ook altijd met -pedantic ?

Net als een hond, lijkt een goeie compiler op z'n baasje
-Wall, -Wextra -pedantic, -Weffc++, -Werror

[_Peter2_]

H!GHGuY schreef op maandag 22 juli 2013 @ 12:33:
[...]


Net als een hond, lijkt een goeie compiler op z'n baasje
-Wall, -Wextra -pedantic, -Weffc++, -Werror

-Waf -Woef?

Kon het niet laten

[Zoijar]

H!GHGuY schreef op maandag 22 juli 2013 @ 12:33:
Net als een hond, lijkt een goeie compiler op z'n baasje
-Wall, -Wextra -pedantic, -Weffc++, -Werror

Dat ziet er goed uit in ieder geval -- kan niet oordelen over het baasje Vervelende vind ik alleen altijd die warnings als unused variable ed. Kan je er wel een unused macro omheenzetten, maar dat is ook een beetje vies... eigenlijk zou men daar wel C++11 attributes voor kunnen introduceren: void foo(int x [[std::unused]]) {} Als je hem dan toch gebruikt kan je compiler ook een warning: using unused variable uitspugen. Ik vind attributes hier ook wel geschikt voor omdat het echt meta-informatie voor je compiler is.

[ Voor 14% gewijzigd door Zoijar op 22-07-2013 13:57 ]

[Hatsieflatsie]

NMe schreef op vrijdag 19 juli 2013 @ 10:22:
[...]

Ten eerste is dit niet gerelateerd aan dit topic en ten tweede is dit prima te vinden op het internet.

Bestaan er trefwoorden daarvoor, waar ik kan zoeken waarom bijv Dog = d geen optie zou zijn?

[NMe]

Om te beginnen omdat de assignment-operator right-associative is (niet lullig bedoeld, maar dat is toch écht programmeren les 1) en het dus d = Dog zou moeten zijn in dat geval. Daarnaast omdat je op die manier d gelijk zou stellen aan de class Dog in plaats van hem te instantiëren in een object, wat weer behandeld wordt in je boek. Sowieso staat je vraag min of meer uitgelegd op pagina 54 van je boek. Lees het boek nou gewoon eens rustig door voor je vragen stelt. Jij moet helemaal nog niet op zoek naar trefwoorden, je hebt éérst de basis nodig.

[ Voor 5% gewijzigd door NMe op 22-07-2013 18:16 ]

[Daos]

(right-)associative is niet relevant hier. Dat zegt hoe haakjes geplaatst moeten worden. Neem bijvoorbeeld:
a + b + c. + is left-associative en wordt (a + b) + c;
a = b = c. = is right-associative en wordt a = (b = c).


In Java moet je je variabelen eerst declareren (term: 'variable declaration') en een type geven. Dit doe je zo:

Java:

Dog d;

Vervolgens ga je iets opslaan in d. Twee termen die je hiervoor zoekt zijn 'lvalue' en 'rvalue'. Links van = moet een lvalue staan zoals een variabele waarin je iets kan opslaan. In jouw voorbeeld is dit d. Rechts moet de waarde staan die je wilt opslaan. In jouw geval is dit een nieuwe Dog oftewel:

Java:

d = new Dog("Fikkie");

Declareren en een initiele waarde geven kan ook tegelijkertijd. De term hiervoor is 'variable definition'. Dit doe je zo:

Java:

Dog d = new Dog("Fikkie");

[Hatsieflatsie]

Bedankt voor jullie zéér behulpzame antwoorden, NMe en onvolprezen Daos. .

Nu kan ik weer verder zonder met prangende vragen te zitten, ook al lees ik het hele boek door.

[bwerg]

Daos schreef op maandag 22 juli 2013 @ 18:50:
Rechts moet de waarde staan die je wilt opslaan. In jouw geval is dit een nieuwe Dog oftewel:

Java:

d = new Dog("Fikkie");

Toevoeging: het kan ook een oude dog zijn, dus vandaar dat het type (Dog d) niet mag impliceren dat je ook een nieuw object aanmaakt (= new Dog()) met een constructor. Je mag ook doen:

Java:

Dog d1 = new Dog();
Dog d2 = d1;

Waarbij d2 wel een nieuwe variabele is, maar geen nieuw object.

Dus dan moge duidelijk zijn dat in de regel

Java:

Dog d = new Dog("Fikkie");

echt geen overbodige dingen staan.

Maar dat wordt allemaal wel duidelijk als je wat leest over references.

[ Voor 5% gewijzigd door bwerg op 22-07-2013 21:39 ]

[Zoijar]

Het 'new' keyword zou strict gezien niet nodig zijn, maar zo werkt Java nou eenmaal. In een nieuwe taal, met een slimmere compiler/parser zou je het anders kunnen doen.

Java heeft overigens geen references (ook al heten ze zo, "foutje" in de specificatie), alleen pointers (die pass-by-value worden doorgegeven) Maar ik zal het niet te ingewikkeld/verwarrend maken

[ Voor 7% gewijzigd door Zoijar op 22-07-2013 23:26 ]

[Woy]

Zoijar schreef op maandag 22 juli 2013 @ 23:25:
Het 'new' keyword zou strict gezien niet nodig zijn, maar zo werkt Java nou eenmaal. In een nieuwe taal, met een slimmere compiler/parser zou je het anders kunnen doen.

Het zou alleen wel wat ambiguïteit opleveren tussen een method Dog en de constructor van Dog. Maar verder zou dat prima mogelijk zijn. Dat is natuurlijk op te lossen met een syntax als C++, of door de typename er voor te zetten, maar dan vindt ik het new keyword niet zo storend, want het schept IMHO ook duidelijkheid over wat je doet.

Java heeft overigens geen references (ook al heten ze zo, "foutje" in de specificatie), alleen pointers (die pass-by-value worden doorgegeven) Maar ik zal het niet te ingewikkeld/verwarrend maken

Wat is jouw definitie van reference dan? Ik ben het er mee eens dat het meer op een pointer van C++ lijkt, maar zie niet waarom het geen reference kan heten. Die reference wordt natuurlijk wel by-value doorgegeven

[ Voor 10% gewijzigd door Woy op 23-07-2013 08:42 ]

[Herko_ter_Horst]

Zoijar schreef op maandag 22 juli 2013 @ 23:25:
Java heeft overigens geen references (ook al heten ze zo, "foutje" in de specificatie), alleen pointers (die pass-by-value worden doorgegeven) Maar ik zal het niet te ingewikkeld/verwarrend maken

Omdat je volgens mij iets zegt wat niet klopt, moet ik hier toch even op ingaan, want zonder verdere definitie van termen kom je hier niet mee weg

References in Java zijn een implementatie van het algemene begrip reference, maar het zijn beslist geen pointers.

De term 'reference' is echt geen foutje in de spec. References in Java zijn een laagje over pointers heen. Je hebt in Java niet rechtstreeks toegang tot de onderliggende pointer. M.a.w. Java kent geen pointers zoals C/C++ (bijv. pointer-arithmetic is niet mogelijk).

En ja, aangezien alles in Java by-value wordt doorgegeven, worden ook references by-value doorgegeven.

[Zoijar]

Omdat references een alias zijn voor hetzelfde object, en java pointers by-value doorgeeft.

Java:

void foo(Dog d) { // d is pass-by-value pointer; d is _local_
    d = new Dog("woef");
}

Dog a = new Dog("fikkie");
foo(a);
// a = "fikkie" hier

C++:

void foo(Dog& d) { // & = reference, is alias to caller's object, 'd' and 'a' are one and the same
    d = Dog("woef");
}

Dog a("fikkie");
foo(a);
// a = "woef" hier

Toen ik Java moest leren op de universiteit kon ik al redelijk programmeren in C++ en assembly, en is dit aspect van java nooit goed en duidelijk uitgelegd. Daarom heeft het een tijd geduurd voordat ik het echt begreep. Terwijl het eigenlijk heel simpel is. Ik wou dat iemand mij dit in de eerste week had verteld, in plaats van "java is pass-by-value, alleen objecten zijn references en strings zijn immutable" met wat handgewuif

Het zijn alleen references in de zin dat je er geen pointer arithmetic op kan doen; verder gedragen ze zich exact als pointers, inclusief een speciale null reference (C++ kent die ook niet; je kan geen alias hebben naar een object dat niet bestaat)

[ Voor 46% gewijzigd door Zoijar op 23-07-2013 09:29 ]

[Woy]

Dat is inderdaad de C++ definitie, maar dat maakt niet meteen dat het in Java verkeerd is. Ook in C#/.NET noemen ze het gewoon references, die standaard by-value doorgegeven worden. Daarom is het ook een MSDN: NullReferenceException Class (System)

Nou is dat wel iets geks in Java, want daar is het een NullPointerException

[ Voor 64% gewijzigd door Woy op 23-07-2013 09:21 ]

[Zoijar]

Woy schreef op dinsdag 23 juli 2013 @ 09:19:
Dat is inderdaad de C++ definitie, maar dat maakt niet meteen dat het in Java verkeerd is.

Reference als alias was op het moment dat Java bedacht werd zo'n beetje de interpretatie in elke taal (in het bijzonder C/C++ met een groot marktaandeel). Dan neem je niet hetzelfde woord over en geeft er een andere betekenis aan.Tenminste, blijkbaar wel, maar ik zie dat als 'foutje', al dan niet moedwillig. De rede is dat Java gemarket moest worden als veilig, en references waren veilig(er).

Woy schreef op dinsdag 23 juli 2013 @ 08:39:
Ik ben het er mee eens dat het meer op een pointer van C++ lijkt, maar zie niet waarom het geen reference kan heten.

Omdat ik de rem in een nieuw auto-ontwerp ook niet ineens koppeling noem

[ Voor 33% gewijzigd door Zoijar op 23-07-2013 09:32 ]

[Woy]

Maar het is in feite ook een alias van het object, alleen wordt die alias by-value doorgegeven waardoor er een nieuw alias naar hetzelfde object onstaat.

Een Java reference is ook niet hetzelfde als een C++ pointer, dus ook logisch dat ze het niet zo genoemd hebben. Dan hadden ze een compleet andere term moeten bedenken. IMHO is reference niet zo'n gekke term, ook al heeft het een andere betekenis dan in C++.

[Zoijar]

Het is gewoon erg verwarrend en ze hadden dat kunnen voorkomen door het pointers te noemen (wat het zijn: "The reference values (often just references) are pointers to these objects") met een expliciete note dat alle pointer arithmetic verboden/onmogelijk is. Dan had ik het persoonlijk vanaf dag 1 begrepen en niet pas jaren later

(het is imho echt puur gedaan omdat men altijd riep "oh, C/C++, moeilijk met pointers" en "pointer errors, pointers zijn foutgevoelig" Laten we het dan iets anders noemen om die associatie met moeilijk en onveilig te ontwijken in Java... ik ben geen grote fan van de taal zoals je ziet )

[ Voor 30% gewijzigd door Zoijar op 23-07-2013 09:58 ]

[Woy]

Tja, pointer en reference liggen gewoon erg dicht bij elkaar. Het is niet voor niks dat je voor pointers gebruik maakt van de reference en dereference operators

IMHO zijn zowel de definitie van pointer als reference uit C++ niet de juiste begrippen voor een Java reference. Ik geloof best dat de aversie van de C++ pointer de doorslag heeft gegeven om het references te noemen, maar ik zou zeker niet zo ver gaan om het fout te noemen.

Het feit dat je het pas jaren later doorhad is ook niet echt een goed argument IMHO, want het is niet alsof het niet duidelijk gespecificeerd is

[Herko_ter_Horst]

C/C++ pointers en references zijn twee implementaties van het algemene begrip "reference". Java references zijn een andere implementatie. Belangrijke verschillen met pointers zijn niet alleen het ontbreken van pointer arithmetic, maar ook de typing (en de bijbehorende bescherming tegen "foute" conversies).

En daarbij: de VM spec vereist dat references ondersteund worden, niet dat daarvoor pointers gebruikt worden.

[.oisyn]

Herko_ter_Horst schreef op dinsdag 23 juli 2013 @ 12:01:
maar ook de typing (en de bijbehorende bescherming tegen "foute" conversies).

Er zit zo goed als geen verschil tussen C++'s dynamic_cast en Java's cast. Behalve dat Java een C-style syntax gebruikt, wat in C++ resulteert in een static_cast danwel reinterpret_cast, al dan niet gecombineerd met een const_cast, en over het algemeen dus afgeraden wordt om te gebruiken juist omdat je hier zo snel mee de fout in kan gaan.

[ Voor 5% gewijzigd door .oisyn op 23-07-2013 12:10 ]

[Zoijar]

De verschillen in pointer gedrag zijn slechts wat restricties voor veiligheid. Het verschil met (C++) references of aliases is fundamenteel en functioneel. Het klassieke voorbeeld is dat het in Java zonder alias references onmogelijk is een directe swap functie te schrijven. References halen iets van buiten naar binnen je scope onder een andere naam.

Maar ok, het is maar een woord... Ik zal verder niet moeilijk doen Het belangrijkste punt is "java reference != C++ reference", en "Java reference ~= C++ pointer"

[Herko_ter_Horst]

.oisyn schreef op dinsdag 23 juli 2013 @ 12:10:
[...]

Er zit zo goed als geen verschil tussen C++'s dynamic_cast en Java's cast. Behalve dat Java een C-style syntax gebruikt, wat in C++ resulteert in een static_cast danwel reinterpret_cast, al dan niet gecombineerd met een const_cast, en over het algemeen dus afgeraden wordt om te gebruiken juist omdat je hier zo snel mee de fout in kan gaan.

Mijn C++ is te roestig om deze uitspraak op waarde te kunnen schatten, maar het voorbeeld dat ik via Googlen vond, is dat het met pointers mogelijk is om een int* te casten naar een char*, waarbij er dus herinterpretatie plaats vindt van wat er op dat geheugenadres is opgeslagen (wat in dit geval goed gaat omdat de geheugenstructuur toevallig gelijk is). Dit kan met Java references/casts niet.

Zoijar schreef op dinsdag 23 juli 2013 @ 13:10:
De verschillen in pointer gedrag zijn slechts wat restricties voor veiligheid. Het verschil met (C++) references of aliases is fundamenteel en functioneel. Het klassieke voorbeeld is dat het in Java zonder alias references onmogelijk is een directe swap functie te schrijven. References halen iets van buiten naar binnen je scope onder een andere naam.

M.i. is het verschil met pointers net zo functioneel en fundamenteel.

Het swap-voorbeeld heeft overigens niets te maken met of Java references nou meer op C++ references lijken of op pointers, maar met pass-by-reference vs. pass-by-value semantiek bij het doorgeven van variabelen. Als Java pass-by-reference semantiek zou implementeren, zou het prima mogelijk zijn om een directe swap-method te implementeren, ook voor de huidige references.

Dus wat mij betreft: "Java reference != C++ reference", en "Java reference != C++ pointer".

[ Voor 41% gewijzigd door Herko_ter_Horst op 23-07-2013 13:45 ]

[.oisyn]

Herko_ter_Horst schreef op dinsdag 23 juli 2013 @ 13:20:
[...]

Mijn C++ is te roestig om deze uitspraak op waarde te kunnen schatten, maar het voorbeeld dat ik via Googlen vond, is dat het met pointers mogelijk is om een int* te casten naar een char*, waarbij er dus herinterpretatie plaats vindt van wat er op dat geheugenadres is opgeslagen (wat in dit geval goed gaat omdat de geheugenstructuur toevallig gelijk is).

Klopt, als je dat wilt dan kán dat ja. Maar dat maakt een cast in C++ niet meteen onveilig - alleen reinterpret_cast is onveilig (en static_cast tot op zekere hoogte omdat je kunt downcasten naar een verkeerde klasse - een Dier* naar een Hond* bijvoorbeeld terwijl het eigenlijk een Kat is), maar ik zei niet voor niets dat het vergelijkbaar was met dynamic_cast waar gewoon zowel compiletime als runtime type checking op plaatsvindt.

Als je netjes gebruik maakt van de juiste cast methodes zul je nooit per ongeluk een foute cast doen.

[ Voor 5% gewijzigd door .oisyn op 23-07-2013 14:40 ]