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

[Hatsieflatsie]

Bij het bestuderen van Java, nam ik een stuk code door voor een spel met de computer. Dit code laat 3 bots een getal raden, totdat een bot op juiste getal komt. Dan krijg je de melding dat de juiste getal tussen 1 en 10 geraden is. De code werkt als volgt:

Java:

public class GuessGame {
Player p1;
Player p2;
Player p3; [b](3 player objecten dus)[/b]

public void startGame() {
p1 = new Player();
p2 = new Player();
p3 = new Player();[b](Er worden 3 player objecten gecreërd)[/b]

int guessp1 = 0;
int guessp2 = 0;
int guessp3 = 0; [b](de drie variabelen voor de drie spelers)[/b]

boolean p1isRight = false;
boolean p2isRight = false;
boolean p3isRight = false;
int targetNumber = (int) (Math.random() * 10);
System.out.println("I'm thinking of a number between 0 and 9...";);

while(true) {[b](Ik vraag mij af waarom er 'true' staat? Er wordt namelijk niet aan een definitie voldaan, waardoor het 'true' is, en de code dus niet zou moeten draaien)[/b]
System.out.println("Number to guess is " + targetNumber);
p1.guess();
p2.guess();
p3.guess();
guessp1 = p1.number;
System.out.println("Player one guessed " + guessp1);
guessp2 = p2.number;
System.out.println("Player two guessed " + guessp2);
guessp3 = p3.number;
System.out.println("Player three guessed " + guessp3);
if (guessp1 == targetNumber) {
p1isRight = true;
}
if (guessp2 == targetNumber) {
p2isRight = true;
}
if (guessp3 == targetNumber) {
p3isRight = true;
}
if (p1isRight || p2isRight || p3isRight) {
System.out.println("We have a winner!");
System.out.println("Player one got it right? " + p1isRight);
System.out.println("Player two got it right? " + p2isRight);
System.out.println("Player three got it right? " + p3isRight);
System.out.println("Game is over.");
break; [b](spel is over, daarom wordt het hier afgebroken)[/b]

} else {
[b](spel gaat door, totdat iemand juiste getal geraden heeft)[/b]
System.out.println("Players will have to try again.");
} // end if/else
} // end loop
} // end method
} // end class

Dit levert de volgende output op:

%java GameLauncher
I'm thinking of a number between 0 and 9...
Number to guess is 7
I'm guessing 1
I'm guessing 9
I'm guessing 9
Player one guessed 1
Player two guessed 9
Player three guessed 9
Players will have to try again.
Number to guess is 7
I'm guessing 7
I'm guessing 5
I'm guessing 0
Player one guessed 7
Player two guessed 5
Player three guessed 0
We have a winner!
Player one got it right? true
Player two got it right? false
Player three got it right? false
Game is over.

Voor overzichtelijkheid nogmaals mijn vragen:
1. Regel 21: "while(true)" {. k vraag mij af waarom er 'true' staat? Er wordt namelijk niet aan een definitie voldaan waardoor het 'true' zou zijn, en de code dus niet zou moeten draaien?
2. Regel 11: int guessp1 = 0; > Er wordt een 0 toegewezen aan guessp1/2/3. Hoe kan dit getal dan veranderen met guessp1? Dat zie ik in de code niet terug.

Iemand die mij uit de verwarring kan helpen?

[ Voor 3% gewijzigd door BtM909 op 19-07-2013 00:07 ]

[Zoijar]

while (true) is altijd waar en dus een oneindige loop die nooit stopt.

in regel 47 staat een 'break', dan stop je de omvattende loop ongeacht andere condities.

Niet heel netjes overigens.

[markvt]

1:
while(true)
Is een eindeloze loop.Maar of dat de juiste manier is om dat te doen...

2:
Line 26:
guessp1 = p1.number;

[CyBeR]

Hatsieflatsie schreef op dinsdag 16 juli 2013 @ 23:02:
Voor overzichtelijkheid nogmaals mijn vragen:
1. Regel 21: "while(true)" {. k vraag mij af waarom er 'true' staat? Er wordt namelijk niet aan een definitie voldaan waardoor het 'true' zou zijn, en de code dus niet zou moeten draaien? '

Jawel. Er staat toch 'true' of niet soms?

2. Regel 11: int guessp1 = 0; > Er wordt een 0 toegewezen aan guessp1/2/3. Hoe kan dit getal dan veranderen met guessp1? Dat zie ik in de code niet terug.

regel 26 was je niet opgevallen?

[CurlyMo]

1)

code:

while(true) { }

Dit betekent gewoon dat je een oneindige loop start totdat je hem onderbreekt met break. Dat had je dus zelf al gezien. Er had ook dit kunnen staan, maar dat is meer code:

code:

while(!p1isRight && !p2isRight && !p3isRight) { }

2)

code:

p1.guess();

gues() is een functie van de class Player waarin een random nummer wordt gegenereerd. Vervolgens wordt deze in regel 26 dus aan guessp1 toegewezen. De inhoud van de class Player heb je niet gepost.

[ Voor 4% gewijzigd door CurlyMo op 16-07-2013 23:20 ]

[Douweegbertje]

punt 1: dat is gewoon ruk.
Zoals hierboven al wordt gezegd, zou je in feite een statement ff moeten neerzetten om bijv. dit soort verwarringen niet te krijgen.

Een simpele :

while(!notGuessed)
{
doe dingen
}
else
{
yay winnaar
}


zou dus al een stuk beter zijn.

[sig69]

while / else??

[Hatsieflatsie]

Duidelijk, bedankt voor jullie input. De code van class Player staat helaas niet bij vermeld, maar het is mij al stuk duidelijker. .

Ondanks dat het slordig is, werkt het wel. Blijft de vraag wel waarom de intreperter vandaan haalt waar while(true) aan moet voldoen? Tegenover wat test hij of de waarde 'true' overeen komt?

[ Voor 6% gewijzigd door Hatsieflatsie op 17-07-2013 01:22 ]

[NMe]

Kom op, je mag je ook wel een klein beetje inlezen hoor. While doet niet meer dan de expressie tussen haakjes evalueren, en als die op true uitkomt, dan wordt de loop nog een iteratie voortgezet. Zo niet, dan wordt hij beëindigd. True evalueert niet alleen naar true maar is gewoon true en dus blijft die loop oneindig doorgaan tenzij je er in de code zelf uit breakt.

@markvt & douweegbertje: dit is een vrij gangbare manier van het onderhouden van een loop. Games zijn veel minder (lees: niet) event based en veel meer procedureel. Een game zal dus vrijwel altijd een main loop hebben die één voor één alle benodigde checks doet. Vrijwel altijd zit je statemachine-code daar ook vrij dichtbij. Een while (!guessed) kan in principe ook, maar de meeste gameframeworks die ik ken sturen erop aan om ook je mainmenu en dergelijke in diezelfde loop te zetten en uit te filteren met eerdergenoemde state machine. Het is dan veel eenvoudiger en makkelijker leesbaar om gewoon een while (true) te doen en in de code zelf op de benodigde plekken te breaken.

[Acid_Burn]

Het is toch niet zo ingewikkeld? Op de plaats waar 'true' staat moet een boolean waarde staan. Of die nou voortkomt uit een vergelijking.. a=b of uit een gedefinieerde waarde welke een boolean is maakt niet uit.

[Hydra]

Dit bewijst wel m'n eerdere opmerking in een ander topic dat code bekijken van anderen niet bijster leerzaam is en je bovendien nogal eens de verkeerde dingen aan kan leren.

Oftewel: koop een goed boek, dan worden dit soort zaken in 't eerste hoofdstuk al uitgelegd.

[farlane]

Java:

while(!notGuessed)
{ 
...
} 

zou dus al een stuk beter zijn.

Really? Jij vind die voorwaarde leesbaar? Doe mij maar een while( true ) kan ik in 1 oogopslag zien wat er gebeurt.

[Douweegbertje]

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

Really? Jij vind die voorwaarde leesbaar? Doe mij maar een while( true ) kan ik in 1 oogopslag zien wat er gebeurt.

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'.

edit; even nog een quote;

100% agree that while (true) is not a good idea because it makes it hard to maintain this code and the way you are escaping the loop is very "goto"esque which is considered bad practice.

Try:

code:

do
{
    //do something
} while (!something);

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

[418O2]

Feitelijk staat er 'niet nietGeraden'

Java:

while(!guessed)

of

Java:

while(notGuessed)

is dat toch netter? Ontkennende booleans zijn niet altijd even handig

[ Voor 16% gewijzigd door 418O2 op 17-07-2013 11:32 ]

[Afvalzak]

Tenzij je echt een infinite loop wilt natuurlijk

Maar die ! bij notGuessed is wel fout?

[Hatsieflatsie]

NMe schreef op woensdag 17 juli 2013 @ 01:28:
Kom op, je mag je ook wel een klein beetje inlezen hoor.

Hydra schreef op woensdag 17 juli 2013 @ 09:39:
Dit bewijst wel m'n eerdere opmerking in een ander topic dat code bekijken van anderen niet bijster leerzaam is en je bovendien nogal eens de verkeerde dingen aan kan leren.

Oftewel: koop een goed boek, dan worden dit soort zaken in 't eerste hoofdstuk al uitgelegd.

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?

[Creepy]

!notGuessed of !guessed of notGuessed. Wanneer moet de loop nu stoppen? Die dubbele not is ontzettend verwarrend en zeker niet leesbaarder dan het origineel

En je maakt mij niet wijs dat een while(true) nergens in je boek wordt uitgelegd, of dat je dat niet zelf had kunnen beredeneren aan de hand van de gegeven info.

[ Voor 34% gewijzigd door Creepy op 17-07-2013 11:36 ]

[Maasluip]

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'.

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 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.

[Afvalzak]

Creepy schreef op woensdag 17 juli 2013 @ 11:33:
!notGuessed of !guessed of notGuessed. Wanneer moet de loop nu stoppen? Die dubbele not is ontzettend verwarrend en zeker niet leesbaarder dan het origineel

while(numberIsNotGuessedByPlayer) dan maar

[Douweegbertje]

Mijn god, gaan we nu lopen zeuren over een benaming?
Het gaat toch over de 'practise', maar best maak er dan !guessed (niet geraden) van, en ga door tot guessed waar is.. of desnoods guessed == 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