[alg] breaks handig of lelijk?

[Alarmnummer]

Naar aanleiding van dit topic:
[rml][ C++] for statement, return[/rml] Wou ik even een nieuw topic openen. Mijn vraag is wat jullie vinden van het break statement.

Ik vind het zelf erg lelijk, omdat het de programma flow in mijn ogen vertroebelt. Als je bv in een lijst een element moet zoeken dan gebruik ik daar een while lus voor omdat je dus niet weet hoeveel iteraties je moet, want het kan namelijk zijn dat je hem bij de 1e vind, maar misschien ook bij de laatste. Sommigen gebruiken hier liever een forlus voor met daarin een break als ze het element gevonden hebben.

Wat is jullie mening hierover en dan is het misschien ook even handig om te weten over welke taal jullie het hebben.

ps: ik programmeer voornamelijk in java.

[whoami]

Een break is handig, en het vertroebeld mi de program flow niet meer dan als je met een while lus de conditie zou aanpassen zoals jij laat doorschemeren.
(Terzijde: een for lus is ook sneller dan een while).

Waarom vind jij dat de program flow door een break statement vertroebeld wordt?

[Varienaja]

I houd niet van breaks. En evenmin van 'exit'.

Die constructies zien eruit als 'hacks', om je progje snel aan de gang te krijgen. Ik zou ze ook alleen voor dat soort 'het-moet-snel-af'-noodgevallen gebruiken.

Ik vind dat mensen die gruwelen van 'goto' ook geen break of exit mogen gebruiken.

[Gerco]

Over het algemeen gebruik ik nooit breaks, gewoon omdat ik ze niet nodig heb, ik heb immers while.

Bij complexe flow in een while of for wil ik ze nog weleens gebruiken om de boel wat duidelijker te maken (1 break is toch wel handiger dan NOG een niveau if() te introduceren).

Kortom, ik gebruik het weinig, maar ik ben er niet bang van, persoonlijk voel ik wel meer voor continue dan voor break, continue heb ik vaker nodig, meestal wil je je while of for voortzetten met de volgende iteratie en niet compleet afbreken.

[whoami]

Varienaja schreef op 08 augustus 2002 @ 10:31:
I houd niet van breaks. En evenmin van 'exit'.

Die constructies zien eruit als 'hacks', om je progje snel aan de gang te krijgen. Ik zou ze ook alleen voor dat soort 'het-moet-snel-af'-noodgevallen gebruiken.

Ik vind dat mensen die gruwelen van 'goto' ook geen break of exit mogen gebruiken.

Een break is geheel iets anders dan een goto. Met een break spring je gewoon uit je lus, terwijl je met een goto naar gelijk welk ander punt in je programma kan springen (bv, midden in een lus).

Ik zie hier totaal geen 'hack' in:

code:

for (int i = 0; i < AantalItems - 1; i++)
{
  if ( Array[i] == ZoekElem)
  {
      Pos = i;
      break;
  }
}

en ik vind die code ook veel compacter dan deze:

code:

while ((!Gevonden) && (i < AantalItems - 1))
{
  if (Array[i] == ZoekElem)
  {
     Pos = i;
     Gevonden = True;
  }
  i++;
}

[Varienaja]

whoami schreef op 08 augustus 2002 @ 10:30:
...en het vertroebeld mi de program flow niet meer dan als je met een while lus de conditie zou aanpassen zoals jij laat doorschemeren.

code:

for i:=1 to 20 do begin
   if Element[i]=Zoekstring then break;
end;

code:

i:=1;
while (i<=20) and (Element[i]<>Zoekstring) do begin
   inc(i);
end;

Beide stukjes code zoeken de juiste 'i'. Maar mekkert Delphi niet altijd dat de for-variabele undefined is na de lus? Dan kan je die constructie dus niet eens gebruiken.

[ Voor 0% gewijzigd door Varienaja op 08-08-2002 10:37 . Reden: Ik vind mijn while mooier :P ]

[whoami]

Varienaja schreef op 08 augustus 2002 @ 10:36:
[...]


Beide stukjes code zoeken de juiste 'i'. Maar mekkert Delphi niet altijd dat de for-variabele undefined is na de lus? Dan kan je die constructie dus niet eens gebruiken.

Idd, dat heb je bij de (modernere) C++ compilers ook. Maar dan doe je het gewoon zoals in mijn voorbeeld.

[Varienaja]

whoami schreef op 08 augustus 2002 @ 10:36:
en ik vind die code ook veel compacter dan deze:

code:

while ((!Gevonden) && (i < AantalItems - 1))
{
  if (Array[i] == ZoekElem)
  {
     Pos = i;
     Gevonden = True;
  }
  i++;
}

Maar die kan je ook zo opschrijven:

code:

while ((Array[i] != ZoekElem) && (i < AantalItems - 1))
{
  i++;
}
Pos = i;

[Gerco]

whoami schreef op 08 augustus 2002 @ 10:36:
[...]
en ik vind die code ook veel compacter dan deze:
code

Dan moet je die ook zo schrijven:

code:

while( ( Array[i] != ZoekElem ) && ( i < AantalItems -1 ) ) {
  i++;
}

edit: hehe, great minds think alike

[ACM]

Varienaja schreef op 08 augustus 2002 @ 10:41:
Maar die kan je ook zo opschrijven:

Sja, maar is dat dan zoveel sneller?
En om het nou zo te doen omdat het 'duidelijker' is...
Doe dan gewoon wat je zelf het prettigst vindt.

Ik gok dat het (ongeveer) naar hetzelfde resultaat compileert.

[Alarmnummer]

whoami schreef op 08 augustus 2002 @ 10:30:
(Terzijde: een for lus is ook sneller dan een while).

In een taal zoals c of pascal zal dat inderdaad wel iets uitmaken. Voor de cpu zal je een forlus beter kunnen optimaliseren (hardwarematige ondersteuning) integenstelling tot de while lus. Maar voor veel talen maakt het niet zoveel uit.

Trouwens ik vind het argument van snelheid meestal vrij slecht. Ik pas niet snel mijn code aan omdat het sneller moet gaan. Ik gebruik bepaalde constructies (oa visitor guide`s) en daarvan weet ik dat ze veel overhead veroorzaken tov de ouderwetse aanpak. Maar een computer is een dienaar van mijn code, en ik niet een dienaar van de computer. En als het trager is, maar acceptabel dan heb ik daar geen problemen mee. *voelt nu de hete adem van c programmeurs in zijn nek*

Waarom vind jij dat de program flow door een break statement vertroebeld wordt?

Ik wou eerst aankomen met het argument dat ik van een for statement niet verwacht dat hij eerder ophoud. Maar als je dat dus wel verwacht (door een break) dan zal de programma flow in jouw ogen minder vertroebelen dan in de mijne.

Wat ik trouwens wel een goed argument vind is dat een break statement niet zorgt voor 1 exit point van een for statement en een conditie wel.

[whoami]

Varienaja schreef op 08 augustus 2002 @ 10:41:
[...]

Maar die kan je ook zo opschrijven:

code:

while ((Array[i] != ZoekElem) && (i < AantalItems - 1))
{
  i++;
}
Pos = i;

Ok, deze while is natuurlijk sneller dan mijn 'while', maar is hij daardoor ook beter? Ik vind deze veel minder duidelijk dan mijn voorbeeld.
In mijn voorbeeld weet ik dat het element gevonden is door de 'Gevonden' variable te testen, jij moet nog eens testen na de while of Array[Pos] == ZoekElem om te weten of het element in de array zat of niet. Ook hier vind ik het testen op 'Gevonden' duidelijker.

[Alarmnummer]

Dit is bij mij een standaard zoek lus.

code:

int i=0;
int indexOf = -1;
int size = array.length;
while(i<size){
   if(array[i]==ZoekElement){
       indexOf = i;
       i=size;
   }else{
       i++;
   }
}

die length had ik trouwens niet in die size hoeven te zetten maar had het voorbeeld eerst met een list en dan voer je dus een methode size() uit (en das onnodig).

[whoami]

Alarmnummer schreef op 08 augustus 2002 @ 10:45:
[...]
Trouwens ik vind het argument van snelheid meestal vrij slecht. Ik pas niet snel mijn code aan omdat het sneller moet gaan.

Tja, jij programmeert dan ook in Java. Jij kent het begrip 'snelheid' niet.
(Flauw he, ik weet het).

En als het trager is, maar acceptabel dan heb ik daar geen problemen mee.

Jij niet, maar wat vinden de gebruikers van jouw programma als ze voor een bepaalde bewerking 20 seconden moeten wachten terwijl je dat zou kunnen optimalizeren naar 5 seconden?

Wat ik trouwens wel een goed argument vind is dat een break statement niet zorgt voor 1 exit point van een for statement en een conditie wel.

Idd, maar dan blijft het in een for nog beperkt tot 2 (Daar waar de break staat en het einde van de lus) wat mi nog overzichtelijk/duidelijk genoeg is

[Verwijderd]

Zowel een break als het niet meer voldoen aan je while-conditie zullen in assembly worden omgezet in een jump naar een "label" na de while/for.. Dus ik denk dat je moet kiezen wat jouw het beste past, waar jij het liefst naar kijkt, waar jij meteen weet wat er bedoeld word.

[Soultaker]

Ah, deze discussie maar weer eens. Ik vermoed dat we hier weinig nieuwe inzichten of standpunten uit verkrijgen.

Ik ben (binnen redelijke grenzen) een voorstander van het gebruik van break in een while lus. Het bekende argument, dat het zinloos is om op een conditie te checken die uitsluitend waar is, wanneer je 'm zelf hebt ingesteld, gaat nog steeds op.

Een 'klassieke' while constructie in de vorm van:

code:

while ( conditie )
{
   ...
   if A break;
   ...
   if B break;
   ...
}

Is 100% automatisch om te zetten naar de break-loze variant:

code:

doBreak = false;
while (!doBreak and conditie)
{
   ...
   if A doBreak = true else
   {
   ...
       if B doBreak = true else
       {   
       ...
       }
   }
}

Zoals je ziet, is de break ge-elimineerd, maar de structuur van de code is exact hetzelfde gebleven. Ik denk dat de break-opposanten het met me eens kunnen zijn, dat deze code niet leesbaarder of anderszins beter is dan de originele versie.

Natuurlijk zou je kunnen zeggen, dat een dergelijke constructie OOK niet goed is. In de praktijk (wanneer aan 'A' en 'B' enkele statements vooraf gaan) is deze constructie echter onvermijdelijk en de tegenstanders van break gebruiken 'm zelf ook vrijwel altijd (zie de code van ACM in het vorige topic!).

Dat brengt me tot mijn belangrijkste punt, dat ik ook al eerder op dit forum heb verwoord trouwens, dat een 'break' een bepaalde betekenis heeft. Een conditie in de while lus kan die betekenis simuleren, maar is niet hetzelfde. Break betekent: spring direct uit de binnenste lus. Een doBreak variabele heeft niet ditzelfde effect, aangezien de code die erna komt ook nog uitgevoerd wordt (tenzij dit voorkomen wordt met een else-clausule) en zelfs eventueel van false naar true gezet wordt.

Als je merkt dat je code schrijft zoals die van ACM of de tweede variant van mijn voorbeeld, dan zou je in moeten zien dat je feitelijk een break constructie probeert te schrijven. Het behoort dan tot een goede programmeerstijl om die intentie ook tot uitdrukking te brengen in de code die geschreven wordt, door dus ook daadwerkelijk een break statement in te voegen.

Daarbij komt dat de meeste van dit soort lussen een paar regels tot een half scherm groot zijn en het overzicht dus toch wel behouden blijft. Handig uitspringen kan hierbij ook helpen; in Perl gaat dat bijvoorbeeld heel mooi, omdat de break dan ook vooraan de regel kan staan:

code:

while ( someCondition )
{
    statement A;
    statement B;
  break if someOtherCondition;
    statement C;
    statement D;
}

Misschien is 'half' uitspringen niet zo mooi (zou ook met volledig uitspringen kunnen) maar het is zo wel heel duidelijk op welke punten de lus onderbroken kan worden; duidelijker dan elke andere vorm, naar mijn idee (ik hou me aanbevolen voor suggesties).

[Alarmnummer]

whoami schreef op 08 augustus 2002 @ 10:53:
Tja, jij programmeert dan ook in Java. Jij kent het begrip 'snelheid' niet.
(Flauw he, ik weet het).

maakt niet uit ik had niet anders van je verwacht

Jij niet, maar wat vinden de gebruikers van jouw programma als ze voor een bepaalde bewerking 20 seconden moeten wachten terwijl je dat zou kunnen optimalizeren naar 5 seconden?

Maar in 99% van de gevallen maakt het niet uit of iets snel of langzaam is omdat ze het geen 10.000 keer per seconde moeten uitvoeren. Op het moment dat dit wel gaat gebeuren dan moet je pas gaan optimaliseren. Verder maak ik met veel plezier gebruik van allerlei geavanceerdere concepten omdat ik in sommige dingen een veel handigere aanpak kan gebruiken dan wat ik op de 'klassieke' manier voorheen heb gedaan.

Double dispatch is bijvoorbeeld zoiets. Dit is standaard niet aanwezig en dit kan ik mbv het visitor design pattern 'simuleren'. Daarnaast maak ik ook nog eens een keer gebruik van guide`s en dan krijg je vrij veel overhead. Maar dit levert mij een zeer fraai framework op waarin ik op een hele elegante manier nieuwe functionaliteit aan kan toevoegen zondat dat ik mijn objecten daarmee besmet.

Programma`s die schrijf je voor jezelf en niet voor gebruikers

Idd, maar dan blijft het in een for nog beperkt tot 2 (Daar waar de break staat en het einde van de lus) wat mi nog overzichtelijk/duidelijk genoeg is

Maar het kunnen er ook meer worden naarmate de code in de for lus langer gaat worden.

[Rataplan]

In het voorbeeld is de iterator bekend (het gaat om een array-structuur) en kan je je afvragen waarom daar geen gebruik van maakt (alleen al om de efficiency ). In het OO-model waar C# omheen is geknutseld geldt dat je de iterator van een datastructuur niet hoeft te kennen:

code:

foreach(DataRowView rijtje in dvTabelletjeView)
  if(rijtje["kolom"].ToString().Equals("WAARDE"))
  {
    rijtje.Actie();
    break;
  }

...en dan - vooropgesteld dat .Actie() maar 1 keer hoeft te worden uitgevoerd - is de break niet alleen handig, d'r is ook nauwelijks een andere manier te bedenken zonder zelf de iterator te hacken. Voor iteraties waarbij een nummering bekend is vind ik de break daarentegen een soort van GoTo, en verwijs ik gaarne naar een grotere denker.

[Soultaker]

Alarmnummer schreef op 08 augustus 2002 @ 10:52:
Dit is bij mij een standaard zoek lus.

code:

int i=0;
int indexOf = -1;
int size = array.length;
while(i<size){
   if(array[i]==ZoekElement){
       indexOf = i;
       i=size;
   }else{
       i++;
   }
}

Dit is echt de meest ranzige code die ik me binnen deze dicussie had kunnen voorstellen! Deze code voldoet dan wel aan een aantal stijlregeltjes, maar de betekenis van de code is ontzettend onduidelijk geworden. Code schrijven die aan een zekere programmeerstijl voldoet is in het algemeen een goed uitgangspunt, maar nu voer je het zo ver door dat de feitelijke code nodeloos ingewikkeld (en daardoor slecht te lezen) is.

Er zijn talloze dingen mis mee; ik wil ze best voor je opsommen maar misschien is dat een leuke opgave voor iets minder ervaren programmeurs. Denk hierbij aan basisprincipes als: elke variabele hoort slechts EEN duidelijk gedefinieerde betekenis te hebben, gegevens moeten op een enkele plaats opgeslagen worden.

Ik heb commentaar op:
1. het gebruik van de while lus
2. het gebruik van de else-clausule van de if-constructie
3. het gebruik van drie variabelen
4. de rare spacing (maar daar ging het hier niet om geloof ik)
edit:
5. het feit dat de constructie niet werkt met een ECHTE iterator in plaats van een integer als iteratievariable

[ACM]

Ben ik wel met soultaker eens, ik vindt het gekste aan die while dat je gauw je i gelijk aan size zet om een stopvoorwaarde te forceren...

Gebruik dan gewoon een break, die _is_ bedoelt om een stop te forceren...

[Alarmnummer]

Soultaker schreef op 08 augustus 2002 @ 11:00:
Dat brengt me tot mijn belangrijkste punt, dat ik ook al eerder op dit forum heb verwoord trouwens, dat een 'break' een bepaalde betekenis heeft. Een conditie in de while lus kan die betekenis simuleren, maar is niet hetzelfde. Break betekent: spring direct uit de binnenste lus. Een doBreak variabele heeft niet ditzelfde effect, aangezien de code die erna komt ook nog uitgevoerd wordt (tenzij dit voorkomen wordt met een else-clausule) en zelfs eventueel van false naar true gezet wordt.

En ik kan me dus eigelijk hier ook goed in vinden. Sommigen die vinden dat een methode niet verlaten mag worden voor het einde, maar ik spring er eigelijk zo snel mogelijk uit (als ik niet in een lus zit wel te verstaan). Hetzelfde geld voor een lus en een break. Met een break geef je aan dat je niet meer in die lus mag vertoeven en dat je er meteen uit wilt.

[whoami]

Alarmnummer schreef op 08 augustus 2002 @ 11:14:
[...]
En ik kan me dus eigelijk hier ook goed in vinden. Sommigen die vinden dat een methode niet verlaten mag worden voor het einde, maar ik spring er eigelijk zo snel mogelijk uit (als ik niet in een lus zit wel te verstaan). Hetzelfde geld voor een lus en een break. Met een break geef je aan dat je niet meer in die lus mag vertoeven en dat je er meteen uit wilt.

Waarom ben je dan een 'tegenstander van break'?

[paulh]

Ik heb opzich niet zoveel tegen break statements als de code binnen de loop weinig statements bevat zoals bij de code in de berichten hierboven. Maar als er binnen die loop echt tientallen regels code staat vind ik het erg vervelend lezen en dan zie ik liever de "nette" oplossing.

[Alarmnummer]

Soultaker schreef op 08 augustus 2002 @ 11:09:
1. het gebruik van de while lus

Als je uitgaat van het feit dat je een forlus niet mag breaken dan is een while lus het alternatief.

2. het gebruik van de else-clausule van de if-constructie

Eigelijk is het gebruik om het niet te doen dom. Je hebt namelijk 2 situaties: 1 je hebt hem gevonden, 2 je hebt hem niet gevonden en die situatues behandel je onafhankelijk van elkaar.

3. het gebruik van drie variabelen

Als je even beter had gelezen dan had je kunnen zien dan die size niet nodig was geweest, maar ik heb het voorbeeld eerst geschreven met een list en daarop moet je een size methode uitvoeren. Dus ik cache die dingen altijd

4. de rare spacing (maar daar ging het hier niet om geloof ik)

Zoals je ziet ben ik het dus 100% met je oneens.

Het enigste waarin ik me kan vinden is dat je die index misbruikt.

[edit]

5. het feit dat de constructie niet werkt met een ECHTE iterator in plaats van een integer als iteratievariable

Jazekers.

code:

Iterator itt = ..;
int indexOf = -1;
int i = 0;
boolean proceed = itt.hasNext();
while(proceed){
    if(itt.next() == zoekObject){
         indexOf = i;
         proceed = false;
    }else{
         i++;
         proceed = itt.hasNext();
    }
}

[Soultaker]

paulh schreef op 08 augustus 2002 @ 11:16:
Maar als er binnen die loop echt tientallen regels code staat vind ik het erg vervelend lezen en dan zie ik liever de "nette" oplossing.

De vraag is, of het ook maar in het minst moeilijker is om een 'break' statement in een grote lap code te bespeuren, dan een 'doBreak = true' of 'i = size' statement. Het voordeel van het break statement is dat er geen twijfel kan bestaan over wat het voor effect op de lus heeft; met een 'i = size' valt dat nog maar te bezien.

[Zoijar]

Hmm ik denk dat je eingelijk alleen break zou moeten gebruiken in een lang switch statement. En die gebruik je al niet vaak.

Volgens mij hangt er namelijk een theoretisch probleem aan break, dat je geen control flow meer kan bewijzen oid...wat was het ook al weer. Bovendien kan je alles zo omschrijven dat je geen break nodig hebt.

[whoami]

Soultaker schreef op 08 augustus 2002 @ 11:20:
[...]

De vraag is, of het ook maar in het minst moeilijker is om een 'break' statement in een grote lap code te bespeuren, dan een 'doBreak = true' of 'i = size' statement. Het voordeel van het break statement is dat er geen twijfel kan bestaan over wat het voor effect op de lus heeft; met een 'i = size' valt dat nog maar te bezien.

Idd, als je een break statement in de code tegenkomt, dan weet je direct wat de betekenis daarvan is, en dan gaat er gelijk een lampje branden van 'ach, hier wordt uit de lus gesprongen', terwijl dit bij een aanpassing van de conditie niet altijd even duidelijk is....

[Soultaker]

Alarmnummer schreef op 08 augustus 2002 @ 11:19:
Als je uitgaat van het feit dat je een forlus niet mag breaken dan is een while lus het alternatief.

Dat is echter een onzin aanname. Een while lus gebruik je als je elke iteratie een conditie moet checken. Een for lus gebruik je als je lus een initialisatiefase kent, elke iteratie een conditie checked en aan het eind van de lus de staat aanpast.

Jou code komt 100% overeen met:

code:

for(i = 0; i < size; i++)
{
   ...
}

Het verschil is, dat in het geval de for-lus, je deze standaardconstructie expliciet aangeduid hebt door de for-constructie te gebruiken en ik bij de while-variant maar moet gokken wat je initialisatiefase ("hoort int i = 0 daar bij? ja, schijnbaar wel, maar dat is niet duidelijk") en het statement dat altijd wordt uitgevoerd is.

Ook is nu meteen duidelijk, dat de lus 'veilig' is; mits i niet binnen de lus gewijzigd wordt, zal de lus vroeger of later afgelopen zijn. Dat is ook het argument om niet 'i = size' te schrijven (wat, zie puntje 5, met een iterator niet altijd werkt) maar een break statement te gebruiken.

Als je even beter had gelezen dan had je kunnen zien dan die size niet nodig was geweest, maar ik heb het voorbeeld eerst geschreven met een list en daarop moet je een size methode uitvoeren. Dus ik cache die dingen altijd

Dat had ik heel goed begrepen; ik doelde er vooral op dat je een indexOf en een 'i' (voor index, vermoed ik?) gebruikt. Als beiden een index aanduiden, en indexOf KAN eigenlijk niet anders dan 'i' zijn, dan kun je net zo goed indexOf afschaffen.

De correcte code was natuurlijk:

code:

int i;
for (i = 0 ; i < size ; ++ i)
    if (array[i] == whatever) break;

(Remind me: hoe zit het met scoping in een for-lus in Java? Bestaat 'int i', gedefinieerd in initialisatiefase van de for-lus, nog buiten de lus, zoals bij de oude C++ standaard?). Korter, duidelijker en zuiverdere code kan bijna niet! (<-- PAS OP! Eigen mening )

[Soultaker]

Alarmnummer schreef op 08 augustus 2002 @ 11:19:

code:

Iterator itt = ..;
int indexOf = -1;
int i = 0;
boolean proceed = itt.hasNext();
while(proceed){
    if(itt.next() == zoekObject){
         indexOf = i;
         proceed = false;
    }else{
         i++;
         proceed = itt.hasNext();
    }
}

Ten eerste: ARGH! 4 variabelen!!! En ik moet als programmeur allemaal bedenken wat ze betekenen??

Ten tweede:

De vraag is, of het ook maar in het minst moeilijker is om een 'break' statement in een grote lap code te bespeuren, dan een 'doBreak = true' of 'i = size' statement. Het voordeel van het break statement is dat er geen twijfel kan bestaan over wat het voor effect op de lus heeft; met een 'i = size' valt dat nog maar te bezien.

Precies hetzelfde geldt voor 'proceed'. Wat een gekunstelde constructie! Om maar weer te vergelijken:

code:

Iterator i;
for ( i = getIterator() ; i.valid(); i++)
   if (i.current() == gezochtElement) break;

De voordelen (overzichtelijk, helder, geen twijfel over werking en correctheid) zijn weer duidelijk.

_{But I repeat myself...}

edit: Ik denk trouwens dat je code niet helemaal af is; indexOf doet nu een beetje gek.

[Verwijderd]

Alarmnummer schreef op 08 augustus 2002 @ 10:25:
Naar aanleiding van dit topic:
[rml][ C++] for statement, return[/rml] Wou ik even een nieuw topic openen. Mijn vraag is wat jullie vinden van het break statement.

Geweldig statement. Net als het return statement.

Ik vind het zelf erg lelijk, omdat het de programma flow in mijn ogen vertroebelt. Als je bv in een lijst een element moet zoeken dan gebruik ik daar een while lus voor omdat je dus niet weet hoeveel iteraties je moet, want het kan namelijk zijn dat je hem bij de 1e vind, maar misschien ook bij de laatste. Sommigen gebruiken hier liever een forlus voor met daarin een break als ze het element gevonden hebben. Wat is jullie mening hierover en dan is het misschien ook even handig om te weten over welke taal jullie het hebben.

Dit is dezelfde discussie als "1 return in een functie/method vs. multi-returns in een functie/method". De een vindt break geweldig, want je stopt met een lus vanwege een zekere conditie. Iemand anders vindt het lelijk want een lus heeft maar 1 exitpoint, en dat is de conditie in het for/while statement.

Ik vind bv het manual zetten van de variable waarop getest wordt in de for/while loop zodat deze stopt erg lelijk. Maar dat terzijde.

Break in C#'s switch /case vindt ik wel erg lelijk: deze is nodig omdat fall through niet wordt gesupport in switch(). Het is dus een overbodig statement, maar is toegevoegd om (and I quote) "To not confuse C++ developers when they are writing C# code" (c) Eric Gunnerson / Microsoft C# devteam.

Men moet niet zo zeuren over bepaalde statements. Gemier met geoorloofde statements is vaak ook onleesbaar en levert ook belabberde code op: bouw gewoon leesbare code die solide in elkaar steekt.

[Soultaker]

Verwijderd schreef op 08 augustus 2002 @ 11:34:
Men moet niet zo zeuren over bepaalde statements. Gemier met geoorloofde statements is vaak ook onleesbaar en levert ook belabberde code op: bouw gewoon leesbare code die solide in elkaar steekt.

Niet helemaal mee eens; 'standaardcode' is eenvoudiger te lezen en dat is een groot goed als iemand anders dan jezelf (en na een jaar ben je zelf praktisch iemand anders) ooit naar je code moet kijken.

Als ik een standaard lus-constructie zie, dan snap ik meteen wat er gebeurd. Met wazige andere constructies, die misschien ook goed werken, heb ik dat niet. In sommige gevallen is het niet mogelijk, maar 'leesbare code' zal bij voorkeur een soort standaardvorm aan moeten nemen.

[Dash2in1]

Zoijar schreef op 08 augustus 2002 @ 11:22:
Bovendien kan je alles zo omschrijven dat je geen break nodig hebt.

Beetje loos argument, je kan ook alles zo schrijven dat je niet per se een while nodig hebt. Je kan ook alles zo schrijven dat je een * niet nodig hebt, gewoon in een loop een aantal keren optellen

[Soultaker]

Zoijar schreef op 08 augustus 2002 @ 11:22:
Volgens mij hangt er namelijk een theoretisch probleem aan break, dat je geen control flow meer kan bewijzen oid...wat was het ook al weer. Bovendien kan je alles zo omschrijven dat je geen break nodig hebt.

Om maar even door te bouwen op Dash2in1's commentaar: dat is een directe tegenstelling. Als je beweert dat van code die het break-statement NIET gebruikt je 'control flow kan bewijzen' (whatever that is) en tegelijkertijd beweert dat een break uit te drukken is in andere statements (wat we inderdaad al gezien hebben), dan betekent dat natuurlijk ook dat code die WEL het break-statement gebruikt 'bewezen' kan worden. De code MET het break-statement is immers equivalent aan code ZONDER break-statement.

[ACM]

Soultaker schreef op 08 augustus 2002 @ 11:29:
(Remind me: hoe zit het met scoping in een for-lus in Java? Bestaat 'int i', gedefinieerd in initialisatiefase van de for-lus, nog buiten de lus, zoals bij de oude C++ standaard?). Korter, duidelijker en zuiverdere code kan bijna niet! (<-- PAS OP! Eigen mening )

code:

for(int i = 0; i < bla; i++)
{
  // i bekend
}
// i niet meer bekend

Zo zat die scoping, meen ik

[Alarmnummer]

Soultaker schreef op 08 augustus 2002 @ 11:29:
[...]

Dat is echter een onzin aanname. Een while lus gebruik je als je elke iteratie een conditie moet checken. Een for lus gebruik je als je lus een initialisatiefase kent, elke iteratie een conditie checked en aan het eind van de lus de staat aanpast.

Een onzin aanname ook nog Zoals je zelf al zegt moet je bij een for lus iedere iteratie conditie moet checken. Dit moet je dus bij die zoek methode (heb je hem wel gevonden of niet). Een forlus die kan maar 1 conditie checken, en dat is of de index nog klopt. Op basis van jouw eigen argument zou jij zelfs moeten kiezen voor een while lus.

Jou code komt 100% overeen met:

code:

for(i = 0; i < size; i++)
{
   ...
}

Het verschil is, dat in het geval de for-lus, je deze standaardconstructie expliciet aangeduid hebt door de for-constructie te gebruiken en ik bij de while-variant maar moet gokken wat je initialisatiefase ("hoort int i = 0 daar bij? ja, schijnbaar wel, maar dat is niet duidelijk") en het statement dat altijd wordt uitgevoerd is.

als je het gebruik van break statements afkeurt omdat je dus je exit point van een statement verneukt is een while statement het alternatief. En het zal vaker voorkomen dat je initialisatie code voor een statement moet schrijven omdat het gewoon niet anders kan. Zie bv dit voorbeeld van jezelf:

code:

int i;
for (i = 0 ; i < size ; ++ i)
    if (array[i] == whatever) break;

Ook is nu meteen duidelijk, dat de lus 'veilig' is; mits i niet binnen de lus gewijzigd wordt, zal de lus vroeger of later afgelopen zijn.

Daar ben ik het wel mee eens.

Dat is ook het argument om niet 'i = size' te schrijven (wat, zie puntje 5, met een iterator niet altijd werkt) maar een break statement te gebruiken.

Deze constructie bestaat niet in java.

Dat had ik heel goed begrepen; ik doelde er vooral op dat je een indexOf en een 'i' (voor index, vermoed ik?) gebruikt. Als beiden een index aanduiden, en indexOf KAN eigenlijk niet anders dan 'i' zijn, dan kun je net zo goed indexOf afschaffen.

ga nou eens even goed nadenken...

hint hint. stel dat je je zoek element niet hebt gevonden, wat staat er bij jou dan in i en bij mij in indexOf.

[Alarmnummer]

Soultaker schreef op 08 augustus 2002 @ 11:34:
Precies hetzelfde geldt voor 'proceed'. Wat een gekunstelde constructie! Om maar weer te vergelijken:

code:

Iterator i;
for ( i = getIterator() ; i.valid(); i++)
   if (i.current() == gezochtElement) break;

Er zijn genoeg andere die de break verwerpen. Zo gauw je de break gaat verwerpen kom je toch met een while lus en conditie in aanraking.

De voordelen (overzichtelijk, helder, geen twijfel over werking en correctheid) zijn weer duidelijk.

Deze constructie heb je dus niet in java, dus eigelijk kan je niet zo snel een vergelijking maken.

dit is de java versie.

code:

for(Iterator itt = ..;itt.hashNext();){
    if(i.next()==gezochteElement){
        break;      
    }
}

En jouw code doet ook veel minder dan mijn code, die van mij bepaalt tenminste nog de index van het gevonden element

Ik denk trouwens dat je code niet helemaal af is; indexOf doet nu een beetje gek.

Nee hoor, loop hem maar na.


tip:
ik zou proberen om andere mensen wat minder tegen de haren in te strijken. Je wekt de indruk dat alleen jouw pad de juiste is, en dat hoeft niet zo te zijn hoor

[Zoijar]

Soultaker schreef op 08 augustus 2002 @ 11:45:
[...]

Om maar even door te bouwen op Dash2in1's commentaar: dat is een directe tegenstelling. Als je beweert dat van code die het break-statement NIET gebruikt je 'control flow kan bewijzen' (whatever that is) en tegelijkertijd beweert dat een break uit te drukken is in andere statements (wat we inderdaad al gezien hebben), dan betekent dat natuurlijk ook dat code die WEL het break-statement gebruikt 'bewezen' kan worden. De code MET het break-statement is immers equivalent aan code ZONDER break-statement.

Ik denk dat ik in de war was met multi return functies. En zoals ik al zei ik meen me alleen zoiets te herinneren. Met "control flow bewijzen" bedoelde ik een correctsheid bewijs van je code, van die dingen die verplicht zijn in bv vliegtuigen of kern centrales. Als je code op die manier als met multi return branched dan wordt je complexiteit te groot om dit soort bewijzen automatisch te leveren. Dat bedoelde ik eigenlijk. Maar nogmaals weet ik niet of dit nou ook met break zo was, kan me vergissen.

edit:
In ieder geval zal je mij nooit break zien gebruiken, ik vind het een verkapt goto, iets waar we nu juist eindelijk van af zijn

[CyeZ]

De mensen hier gebruiken allemaal zeker nooit het switch() statement?

In het switch statement vind ik break vaak toch erg handig, zeker als je niet meteen uit de betreffende functie wilt springen (want dan zou return ook nog kunnen) maar eerst nog wat andere dingen in de functie wilt doen.

code:

switch(i){
  case 1: blabla();
  case 2: woei();
  case 3: jadajada();
}

lijkt me vaak niet echt het juiste resultaat geven als i in dat geval 1 of 2 is.

[Alarmnummer]

CyeZ schreef op 08 augustus 2002 @ 12:34:
De mensen hier gebruiken allemaal zeker nooit het switch() statement?

In het switch statement vind ik break vaak toch erg handig, zeker als je niet meteen uit de betreffende functie wilt springen (want dan zou return ook nog kunnen) maar eerst nog wat andere dingen in de functie wilt doen.

code:

switch(i){
  case 1: blabla();
  case 2: woei();
  case 3: jadajada();
}

lijkt me vaak niet echt het juiste resultaat geven als i in dat geval 1 of 2 is.

Ik vind dat je hier nooit een breakstatement hoeft neer te zetten want de computer zou automatisch moeten breaken.

[Soultaker]

_{ACM: bedankt voor de verduidelijking. Zo werkt het 'tegenwoordig' in C++ ook; is ook eigenlijk netter.}

Alarmnummer schreef op 08 augustus 2002 @ 12:01:
Een forlus die kan maar 1 conditie checken, en dat is of de index nog klopt. Op basis van jouw eigen argument zou jij zelfs moeten kiezen voor een while lus.

Hmm, leg dat eens uit? Waarom zou een for-lus maar '1 conditie' kunnen checken en een while lus niet? Alles wat je in de while-conditie kwijt kunt, kan je (ook in Java, naar mijn weten) ook in de for-conditie kwijt.

Als je bedoelt dat het omwille van de stijl niet netjes is om extra condities in een for-lus te stoppen die je gebruikt voor het aflopen van een iterator, dan ben ik het met je eens. Daar heb je nu juist break voor.

als je het gebruik van break statements afkeurt omdat je dus je exit point van een statement verneukt is een while statement het alternatief. En het zal vaker voorkomen dat je initialisatie code voor een statement moet schrijven omdat het gewoon niet anders kan.

Dat klopt, maar als het wel kan, dan kun je het het beste gewoon in de for-code doen. Dan heb je initialisatie, voorwaarde en operatie bij elkaar en dat is heel duidelijk.

Deze constructie bestaat niet in java.

Welke constructie bedoel je precies? Ik dacht dat ik wel ongeveer pseudo-Java code schreef.

En jouw code doet ook veel minder dan mijn code, die van mij bepaalt tenminste nog de index van het gevonden element

Maar daar wijst m'n iterator toch naar?

[Soultaker]

Alarmnummer schreef op 08 augustus 2002 @ 12:36:
Ik vind dat je hier nooit een breakstatement hoeft neer te zetten want de computer zou automatisch moeten breaken.

Gelukkig, we zijn het toch nog ergens over eens!

Ik wil trouwens wel een kanttekening plaatsen: lege blocks zouden juist wel moeten doorvallen, waardoor dergelijke constructies mogelijk zijn:

code:

switch(X)
{
   case 'A':
   case 'B':
   case 'C':
        handle A, B, C
   break;
   case 'D':
        handle D
   break;
}

Dit is namelijk precies de situatie waarvoor doorvallen erg handig is (en waarvoor het vaak wordt gebruikt).

Het zou mooier zijn als dat iets duidelijker in de syntax naar voren kwam, dus bijvoorbeeld:

code:

switch(X) {
    case 'A' or 'B' or 'C' {
        handle A, B, C
    }
    case 'D' {
        handle D
     }
}

Doorvallen is dan dus definitief onmogelijk en break overbodig. Ook zou ik verplichte accolades wel mooi vinden; in C/C++/Java zijn die niet verplicht, maar in verband met scoping wil je ze vaak wel hebben.

[Creepy]

Soultaker schreef op 08 augustus 2002 @ 12:37:
_{ACM: bedankt voor de verduidelijking. Zo werkt het 'tegenwoordig' in C++ ook; is ook eigenlijk netter.}

[...]

Hmm, leg dat eens uit? Waarom zou een for-lus maar '1 conditie' kunnen checken en een while lus niet? Alles wat je in de while-conditie kwijt kunt, kan je (ook in Java, naar mijn weten) ook in de for-conditie kwijt.

Als je bedoelt dat het omwille van de stijl niet netjes is om extra condities in een for-lus te stoppen die je gebruikt voor het aflopen van een iterator, dan ben ik het met je eens. Daar heb je nu juist break voor.

Ben ik weer met m'n pascal/Delphi code

code:

for k:=1 to 100 do
   // blaat

In bijv. pascal KAN je maar 1 conditie checken met een for. Als je meerdere condities wilt checken zul je iets anders moeten gebruiken.

Overigens gebruik ik een for als ik AL m'n elementen wil doorlopen. Als ik halverwege er uit wil springen gebruik ik een while.

Wat ik nog wel eens wil gebruiken is het exit statement in Pascal (springt uit de huidige procedure/functie)

code:

procedure doiets;
begin
        if not conditie 1 then
          exit;
       doewat;
        if not conditie2 then
          exit;
      doenogwat;     
end;

om zo geen diepgaande if structuur te krijgen zoals
[code]
if conditie then
begin
doewat;
if conditie2 then
begin
doenogwat
.... etc.
end;
end;

[Alarmnummer]

Soultaker schreef op 08 augustus 2002 @ 12:37:
Hmm, leg dat eens uit? Waarom zou een for-lus maar '1 conditie' kunnen checken en een while lus niet? Alles wat je in de while-conditie kwijt kunt, kan je (ook in Java, naar mijn weten) ook in de for-conditie kwijt.

Als je bedoelt dat het omwille van de stijl niet netjes is om extra condities in een for-lus te stoppen die je gebruikt voor het aflopen van een iterator, dan ben ik het met je eens. Daar heb je nu juist break voor.

Het zou inderdaad wel kunnen dat je een extra conditie opneemt in het conditie gedeelte van de for statement, maar dat is natuurlijk verboden En over die break gaat nu de hele discussie.

Dat klopt, maar als het wel kan, dan kun je het het beste gewoon in de for-code doen. Dan heb je initialisatie, voorwaarde en operatie bij elkaar en dat is heel duidelijk.

Ik vind dit eigelijk een vrij slecht argument om een for ipv een while lus te kiezen op basis van de hoeveelheid initialisatie code.

[Verwijderd]

Gerco schreef op 08 augustus 2002 @ 10:43:
[...]
Dan moet je die ook zo schrijven:

code:

while( ( Array[i] != ZoekElem ) && ( i < AantalItems -1 ) ) {
  i++;
}

edit: hehe, great minds think alike

In this case, the great minds think wrong Dit is crash-code!

Ik zou het veel interessanter vinden als er gediscussierd werd over continue, want dat is echt een hack:

code:

for(int i= 0; i < 10; ++i) {
  for(int j= 0; j < 10; ++j) {
    if(i == j) continue;
    /* doe iets */
  }
}

/* versus: */

for(int i= 0; i < 10; ++i) {
  for(int j= 0; j < 10; ++j) {
    if(i != j) {
      /* doe iets */
    }
  }
}

Wat is het nut van continue? Niks volgens mij, behalve een quick hack...

[Alarmnummer]

Creepy schreef op 08 augustus 2002 @ 12:57:
[...]
Ben ik weer met m'n pascal/Delphi code

code:

for k:=1 to 100 do
   // blaat

In bijv. pascal KAN je maar 1 conditie checken met een for. Als je meerdere condities wilt checken zul je iets anders moeten gebruiken.

Als ik het me goed weet te herinneren, dan wordt 100 in het cx register geplaatst, en bij iedere loop gaat er een af. Je zou zelfs aan de k mogen rotzooien zonder dat je bang hoeft te zijn dat de lus verstoord raakt

Overigens gebruik ik een for als ik AL m'n elementen wil doorlopen. Als ik halverwege er uit wil springen gebruik ik een while.

Wat ik nog wel eens wil gebruiken is het exit statement in Pascal (springt uit de huidige procedure/functie)

Ik vind het ook een drama om al te veel in te gaan springen (gebeurd ook niet zo vaak). En als ik sneller uit een statement kan springen dan doe ik dat graag. MBravenboer was met een taaltje bezig waar in je dus ook maar 1 exit point hebt, maar ik vind dit iets te spartaans aandoen. Een beetje zelfcastijding is leuk, maar dit gaat me toch ook te ver

[Alarmnummer]

Verwijderd schreef op 08 augustus 2002 @ 12:59:
In this case, the great minds think wrong Dit is crash-code!

Afgezien van zijn slecht te lezen conditie, wat is hier mis mee?

[Verwijderd]

Alarmnummer schreef op 08 augustus 2002 @ 13:06:
Afgezien van zijn slecht te lezen conditie, wat is hier mis mee?

Hij checked éérst de break-conditie, en daarna pas of i een index in het geldige bereik is.

[joepP]

Als je break al 'ranzig' vindt, wat moet je dan wel niet van 'return' vinden?

In mijn ogen is de laatste de meest elegante manier voor het afvangen van allerlei pre-condities binnen een funcie. Voorbeeldje:

code:

date convertDate(String s) {
  //check length
  if (s.length != 10) return null;

  //check iets anders
  if (!preconditie) return null;

  //etc etc
  
}

Hoe ga je daar als break/return hater mee om zonder diepe if-constructief te bouwen? Deze code is natuurlijk maar een brak voorbeeldje, maar je begrijpt waar ik naartoe wil.

[ Voor 0% gewijzigd door joepP op 08-08-2002 13:14 . Reden: Voorbeeldje aangepast ]

[Soultaker]

Even om back on topic te komen: het ging niet om de discussie for versus while maar om het al dan niet gebruiken van break.

Verder denk ik dat als ik niet duidelijk kan maken waarom een for-constructie mooier is dan een while-constructie met een initialisatiedeel ervoor en een lusoperatie erbij, ik ook niet kan uitleggen waarom ik break in principe een goed statement vind.

Het gaat mij er vooral om dat je code schrijft die uitdrukt wat de bedoeling is. Er zijn vaak vele manieren om hetzelfde algoritme te schrijven, maar doordat bepaalde constructies op een bepaalde manier geinterpreteerd worden, kan de programmeur zijn code een stuk leesbaarder maken door (waarschijnlijk equivalente) code te schrijven die gebruik maakt van constructies die overeenkom met zijn gedachtengang.

Los van het feit dat dit van nature een hopeloze discussie is, volg ik de manier van discussieren hier niet helemaal (dat is trouwens geen verwijt naar de mensen die aan de discussie deelnemen; het ligt waarschijnlijk aan mezelf). Het is me in ieder geval erg onduidelijk wat nou precies de punten en argumenten zijn.

[Alarmnummer]

Hij checked éérst de break-conditie, en daarna pas of i een index in het geldige bereik is.

auw ik zie het ook..

[Gerco]

Ik had eventjes de i = 0; weggelaten voor de duidelijkheid. Ik heb ook nooit beweerd dat het werkende code was

Als ik dat beweerd had, moest ik ook eronder bepalen OF het element gevonden was en zo ja wat daarvan de index is, dat heb ik ook niet gedaan. Ik schreef dat alleen maar om te bewijzen dat een while() niet per se zo geschreven moest worden als mijn voorganger dat deed.

owjah, en vergeet ook niet om Array te declareren, er gegevens in te stoppen, LastElem te declareren en last but not least: i declareren.

En je hebt inderdaad gelijk over die mooie crash, niet gezien (bovendien was dit minder tikwerk, het meeste stond er al )

[Alarmnummer]

Soultaker schreef op 08 augustus 2002 @ 13:13:
Even om back on topic te komen: het ging niet om de discussie for versus while maar om het al dan niet gebruiken van break.

Het is me in ieder geval erg onduidelijk wat nou precies de punten en argumenten zijn.

misschien is het dan handiger als we een overzicht maken ipv een kletstopic

voordelen:
-maakt code duidelijker omdat je goed aangeeft dat je er meteen uitwilt ipv dat je dit hoeft te regelen met een conditie.

nadelen:
-verneukt de programma flow.

ok.. ik sta open voor nieuw argumenten.

[edit]
ik heb 1 nadeel & voordeel weggehaald omdat deze niet direct betrekking op het break statement had.

[Rataplan]

Alarmnummer schreef op 08 augustus 2002 @ 13:14:
[...]

auw ik zie het ook..

Niet elke compile/compiler optimaliseert de code *zo* dat als de eerste test faalt, de tweede niet meer geevalueerd wordt Slechts 1 van beide condities (i < max) mag dus in de while-lus staan om de code crashproof te maken...

_{$K-}

...of we moeten de break ff op z'n merites gaan beoordelen, in plaats van mekkeren over de while-constructie om een for-loop te implementeren (nofi).

_{Zie ook mijn vorige post}

[Verwijderd]

Verwijderd schreef op 08 augustus 2002 @ 12:59:
Wat is het nut van continue? Niks volgens mij, behalve een quick hack...

Vergelijkbaar met break, alleen gaat continue verder met volgende element uit de lus en kapt break de lus helemaal af. Voor de rest zijn het allebij goto varianten...

Vergelijk:

code:

int
search_item_in_list (list, item)
{
   int i;
   for (i=0;i<length(list);i++) {
      if (list_item(list, i) == item)
         break;
   }
   if (i == length(list))
      return -1;
   return i;
}

met

code:

int
search_item_in_list (list, item)
{
   int i;
   for (i=0;i<length(list);i++) {
      if (list_item(list, i) == item)
         goto found;
   }
   return -1;
found:
   return i;
}

Eventueel kun je zelfs de return al in de for lus doen, maar voor hetzelfde geld wil je nog veel meer dingen in je code doen - dus dat doet er niet zoveel toe.

En ik vind ze allebij valid code - ik prefereer de tweede omdat die een extra length(list) check voorkomt en dus sneller is. Het algemene argument is altijd dat de programmaflow niet duidelijk is. Ik programmeer vrij lowlevel, drivers en systeemlibraries, die moeten gewoon snel zijn. Als je als programmeur de programmaflow dan niet begrijpt, mooi -> next. Dan hoor je niet in mijn project thuis. Ik verwacht van een programmeur hetzelfde als GoT van tweakers -> niveau en kennis en overzicht. Als je dat niet hebt hoef je ook niet in mijn code rond te neuzen want daar heb je dan niks te zoeken. Mijn code is voor programmeurs met niveau, niet voor newbies die een break/continue/goto niet kunnen interpreteren.

Het verschil zit hem natuurlijk ook in wat voor soort programmeren je doet. Kijk, ik doe programmeren voor kernel, daar komt het aan op snelheid en correctheid. Hoe de code eruitziet doet er niet toe (geloof me - ik heb nog vele malen ergere code gezien alshierboven - zit allemaal in je kernel), het gaat erom dat het werkt. That's all that matters. Programmeurs die hier programmeren snappen een continue/break/goto, en kunnen die interpreteren. Als je in een bedrijf zit dat GUI applicaties maakt, een bedrijf met ook mensen die geen interesse hebben in breaks en al dat, dan maakt dat niet uit - voor een GUI zijn die dingen namelijk helemaal niet van belang. Daar gaat het om code die alle mensen uit het bedrijf snappen, code die elegant, mooi, foutloos is. Snelheid is hier niet bepalend.

Vergelijk bovenstaande code nu eens met eentje zonder break en switch en met 1 enkele return.

code:

int
search_item_in_list (list, item)
{
   boolean found = false;
   int i;
   for (i=0;i<length(list) && found = false;i++)
   {
      if (list_item(list) == item)
      {
         found = true;
      }
   }
   if (!found)
      i = -1;
   return i;
}

Je kan zeiken wat je wilt, maar deze versie heeft twee variabelen nodig plus een extra check in de for lus. Vergeleken met de goto variant zit er ook nog eens een extra if in om te kijken of we de waarde gevonden hebben. Ik zie hierboven zelfs versies met vier variabelen staan. Dat is lelijk en onacceptabel. Een kernel moet klein zijn en snel. De rest doet er niet toe. Als elke functies in de kernel 4 in plaats van 1 variabele gebruikte dan.... etc.

Overigens, als ik in java/C++/Gtk+ GUIs programmeer dan beperk ik het gebruik van gotos tot een minimum omdat dat idd niet echt mooi is... breaks en continues zijn echter no problemo - de programmaflow blijft voor mij duidelijk en ik zie niet in waarom ik een extra variabele zou introduceren als een simpel breakje hetzelfde kan. .

[Gerco]

Rataplan schreef op 08 augustus 2002 @ 13:24:
...of we moeten de break ff op z'n merites gaan beoordelen, in plaats van mekkeren over de while-constructie om een for-loop te implementeren (nofi).

Dat is eigenlijk wel een goed idee!

Mijn mening over de break is al bekend, ik gebruik 'em weinig omdat ik 'em weinig nodig heb...

Hebben we het hier ook over meerdere returns in een functie? Die gebruik ik nog weleens vaker om uit een functie te springen (eventueel met foutmelding) als er aan bepaalde precondities niet voldaan is.

code:

int func(int a, int b) {
  if( a > b ) return errorcode;
  if( b < 0 ) return errorcode;

  // Doe iets met a en b waarvoor de 
  // bovenstaande condities niet waar 
  // mogen zijn.
}

[ Voor 0% gewijzigd door Gerco op 08-08-2002 13:30 . Reden: layout ]

[Alarmnummer]

Rataplan schreef op 08 augustus 2002 @ 13:24:
[...]
Niet elke compile/compiler optimaliseert de code *zo* dat als de eerste test faalt, de tweede niet meer geevalueerd wordt Slechts 1 van beide condities (i < max) mag dus in de while-lus staan om de code crashproof te maken...

Yep, correct opgemerkt. Dit zijn altijd gevaarlijke dingen om te doen, omdat je niet kan zeggen of 1 of beiden condities gecontroleerd worden (zelfs de aanname dat de && operator altijd eerst de linkertak gaat bepalen is zoals het woord aanname al zegt: gevaarlijk). Eigelijk vind ik dan dat je het altijd op 1 manier moet schrijven zodat je altijd de juiste werking krijgt ongeacht compiler/runtime omgeving.

[Zoijar]

Alarmnummer schreef op 08 augustus 2002 @ 13:31:
[...]
Yep, correct opgemerkt. Dit zijn altijd gevaarlijke dingen om te doen, omdat je niet kan zeggen of 1 of beiden condities gecontroleerd worden. Eigelijk vind ik dan dat je het altijd op 1 manier moet schrijven zodat je altijd de juiste werking krijgt ongeacht compiler/runtime omgeving.

Dat is ook zo. Bij een logical AND (&&) wordt de tweede expressie niet gevalueerd als de eerste als false evaluate. Dus als je ze omdraait werkt het wel goed. Dat is lazy evaluation.

[Zoijar]

5.14 Logical AND operator

1 The && operator groups lefttoright.
The operands are both implicitly converted to type bool (4). The
result is true if both operands are true and false otherwise. Unlike &, && guarantees lefttoright
evaluation: the second operand is not evaluated if the first operand is false.

2 The result is a bool. All side effects of the first expression except for destruction of temporaries (12.2)
happen before the second expression is evaluated.

[Soultaker]

Rataplan schreef op 08 augustus 2002 @ 13:24:
Niet elke compile/compiler optimaliseert de code *zo* dat als de eerste test faalt, de tweede niet meer geevalueerd wordt Slechts 1 van beide condities (i < max) mag dus in de while-lus staan om de code crashproof te maken...

Alarmnummer schreef op 08 augustus 2002 @ 13:31:
Yep, correct opgemerkt. Dit zijn altijd gevaarlijke dingen om te doen, omdat je niet kan zeggen of 1 of beiden condities gecontroleerd worden (zelfs de aanname dat de && operator altijd eerst de linkertak gaat bepalen is zoals het woord aanname al zegt: gevaarlijk). Eigelijk vind ik dan dat je het altijd op 1 manier moet schrijven zodat je altijd de juiste werking krijgt ongeacht compiler/runtime omgeving.

Sorry, ik wilde wel on-topic gaan, maar zulke grote onzin kan ik niet over m'n kant laten gaan. In zowel C, C++, Java, Perl, Clean (en waarschijnlijk een heleboel andere programmeertalen waar ik niet op kan komen) worden expressies gegarandeerd lazy ge-evalueerd, waarbij de linkerkant van een operatie eerst wordt ge-evalueerd. De voorgestelde code is dus 100% correct en niet afhankelijk van een specifiek platform of een specifieke compiler, aangezien de evaluatie op dit punt goed gespecificeerd is.

Er is hier geen sprake van een 'aanname' maar een eigenschap van (vrijwel elke) programmeertaal. Ik wil niet zeggen dat het in elke programmeertaal zo werkt, maar in alle programmeertalen die tot nu toe aan de orde zijn geweest zeker wel. Laten we dus geen beperkingen invoeren die er niet zijn.

Edit:
Zoijar was me voor! Bedankt, in ieder geval.

[Zoijar]

Ja de standaard zegt het vrij duidelijk...

Dus...ik vind dit mooier dan break:

code:

for (MyList::iterator i = ml.begin(); i != ml.end() && (*i) != "WAARDE"; ++i) {
// doe iets met *i voor alles voor waarde
}

of:

MyList::iterator i = ml.begin();
while (i != ml.end() && (*i) != "WAARDE") {
   ++i;
}
// do iets met (*i) (== "WAARDE") [edit]en i == ml.end() duid op niet gevonden[/edit]

[Creepy]

Alarmnummer schreef op 08 augustus 2002 @ 13:02:
[...]
Als ik het me goed weet te herinneren, dan wordt 100 in het cx register geplaatst, en bij iedere loop gaat er een af. Je zou zelfs aan de k mogen rotzooien zonder dat je bang hoeft te zijn dat de lus verstoord raakt

In theorie misschien.. maar in de pratijk (in Delphi in elk geval...): [Error] scriptunit.pas(65): Assignment to FOR-Loop variable 'i'

Maar als je de index var wilt aanpassen in een for loop, dan ben ik van mening dat je geen for moet gebruiken.

[...]
Ik vind het ook een drama om al te veel in te gaan springen (gebeurd ook niet zo vaak). En als ik sneller uit een statement kan springen dan doe ik dat graag. MBravenboer was met een taaltje bezig waar in je dus ook maar 1 exit point hebt, maar ik vind dit iets te spartaans aandoen. Een beetje zelfcastijding is leuk, maar dit gaat me toch ook te ver

1 exit point?? Welk taaltje was dat? Moet ik me ook maar eens in gaan verdiepen.

Misschien ook wel een leuke discussie wat hier ook wel mee te maken heeft. Het toekennen van een het resultaat van een functie. Waar doe je dat en wanneer? In C is het zo dat als je return <iets> doet, dat dan je huidige functie wordt be-eindigd. In Pascal/Delphi doe je dat met het result:=<iets>, maar je functii/procedure wordt NIET beeindig.

code:

function blaat(a: integer): integer;
begin
     result:=a;
     result:=a+a;
    if result = 10 then
        result:=5;
end;

is (helaas vind ik) werkende code in Delphi.)

[Creepy]

Soultaker schreef op 08 augustus 2002 @ 13:51:
[...]

[...]
Er is hier geen sprake van een 'aanname' maar een eigenschap van (vrijwel elke) programmeertaal. Ik wil niet zeggen dat het in elke programmeertaal zo werkt, maar in alle programmeertalen die tot nu toe aan de orde zijn geweest zeker wel. Laten we dus geen beperkingen invoeren die er niet zijn.

Edit:
Zoijar was me voor! Bedankt, in ieder geval.

Ben ik weer met "m'n" Delphi
In Delphi is dit een compiler optie die aan/uit te schakelen is (complete boolean eval). Standaard staat deze uit, dus werkt het net zoals in eerder genoemde talen.

[Alarmnummer]

Soultaker schreef op 08 augustus 2002 @ 13:51:
Sorry, ik wilde wel on-topic gaan, maar zulke grote onzin kan ik niet over m'n kant laten gaan. In zowel C, C++, Java, Perl, Clean (en waarschijnlijk een heleboel andere programmeertalen waar ik niet op kan komen) worden expressies gegarandeerd lazy ge-evalueerd, waarbij de linkerkant van een operatie eerst wordt ge-evalueerd. De voorgestelde code is dus 100% correct en niet afhankelijk van een specifiek platform of een specifieke compiler, aangezien de evaluatie op dit punt goed gespecificeerd is.

Er is hier geen sprake van een 'aanname' maar een eigenschap van (vrijwel elke) programmeertaal. Ik wil niet zeggen dat het in elke programmeertaal zo werkt, maar in alle programmeertalen die tot nu toe aan de orde zijn geweest zeker wel. Laten we dus geen beperkingen invoeren die er niet zijn.

In een oud expertsysteem waar ik voor de RuG nog een tijdje aan hebt gesleuteld is het helemaal niet zo vanzelf sprekend. Daarbij moet je bij iedere expressie aangeven of je wel of niet wilt optimaliseren.

Verder heb ik dit ook toegepast in het nieuwe expertsysteem wat ik voor hun heb geschreven, dus zo ongebruikelijk is het helemaal niet

En zoals ik al zei. Ik zou echt een beetje proberen me een beetje minder arrogant te gedragen want zo kom je wel een beetje over.

[Alarmnummer]

Zoijar schreef op 08 augustus 2002 @ 13:49:
5.14 Logical AND operator

1 The && operator groups lefttoright.
The operands are both implicitly converted to type bool (4). The
result is true if both operands are true and false otherwise. Unlike &, && guarantees lefttoright
evaluation: the second operand is not evaluated if the first operand is false.

2 The result is a bool. All side effects of the first expression except for destruction of temporaries (12.2)
happen before the second expression is evaluated.

Er is nergens gedefinieerd bij de and operator dat hij altijd gaat optimaliseren. En dit mag dan wel zo zijn voor de meeste programmeertalen, maar dit is geen argument om te zeggen dat dit dan automatisch voor alle talen geldt.

[ACM]

Alarmnummer schreef op 08 augustus 2002 @ 14:08:
Verder heb ik dit ook toegepast in het nieuwe expertsysteem wat ik voor hun heb geschreven, dus zo ongebruikelijk is het helemaal niet

Je leest over het punt 'dat staat duidelijk bij de taal gespecificeerd' heen

ALS het gespecificeed is, dan moet je er vanuit gaan dat dat ook zo gaat en dus kan je dan vertrouwen op de lazy evaluation...
Mocht je dan een compiler tegenkomen die dat fout doet, dan zou ik toch proberen een andere compiler te regelen.

Maar daar wordt het wel enigszins taal-afhankelijk van

[Soultaker]

Alarmnummer schreef op 08 augustus 2002 @ 14:14:
Er is nergens gedefinieerd bij de and operator dat hij altijd gaat optimaliseren. En dit mag dan wel zo zijn voor de meeste programmeertalen, maar dit is geen argument om te zeggen dat dit dan automatisch voor alle talen geldt.

Ja, zo ken ik er nog wel een paar. Er zijn ook zat programmeertalen waar in de and operator niet '&&' heet en dan werkt de code ook niet. Uiteraard is het afhankelijk van de feitelijke specificatie van de taal waar het om gaat, maar het leek me hier wel heel duidelijk dat het ging om een constructie die in een taal als Java of C++ wordt toegepast. Lazy left-hand evaluation is daarbij geen optimalisatie, maar een deel van de taal. Een optimalisatie mag je weglaten en dat is hier duidelijk niet het geval.

Alarmnummer schreef op 08 augustus 2002 @ 14:08:En zoals ik al zei. Ik zou echt een beetje proberen me een beetje minder arrogant te gedragen want zo kom je wel een beetje over.

Dat is schijnbaar de prijs die je betaalt, als je zo'n ueber-1337 programmeur bent als ik.

[TheOneLLama]

Alarmnummer schreef op 08 augustus 2002 @ 12:36:
[...]
Ik vind dat je hier nooit een breakstatement hoeft neer te zetten want de computer zou automatisch moeten breaken.

Hm, ik progammeer net als jou voornamelijk in JAVA, en ik maak redelijk vaak gebruik van switches. Ik denk dat zo'n 20% van m'n cases fallthrough heeft (soms omdat het netter staat soms omdat er ook bruikbaarheid voor is). Als je fallthrough wegneemt mag je van mij switch ook wegnemen. Hadden ze met die C# switch ook mogen doen van mij

[Alarmnummer]

Om martin fowler maar ff te quoten: 'that smells'

In zijn refactorboek legt hij duidelijk uit dat over het algemeen de meeste switches vervangen kunnen worden door polymorphisme Ik zou eerlijk gezegd niet weten wanneer ik voor het laatst een fallthrough heb gebruikt.

[Soultaker]

TheOneLLama schreef op 08 augustus 2002 @ 14:22:
Hm, ik progammeer net als jou voornamelijk in JAVA, en ik maak redelijk vaak gebruik van switches. Ik denk dat zo'n 20% van m'n cases fallthrough heeft (soms omdat het netter staat soms omdat er ook bruikbaarheid voor is). Als je fallthrough wegneemt mag je van mij switch ook wegnemen. Hadden ze met die C# switch ook mogen doen van mij

Wordt er voor het doorvallen dan ook echt code uitgevoerd?

Bijvoorbeeld:

code:

switch (X)
{
  case A:
     doeIets;
  case B:
      enNogIets;
}

Of gebruik je het doorvallen alleen om in meerdere gevallen dezelfde code uit te voeren?

In het laatste geval ben ik met je eens dat het doorvallen een nuttige feature is (zie mijn reactie daarover), in het eerste geval niet.

[Alarmnummer]

[b][message=14672125,noline]Soultaker schreef op 08 augustus 2002 @
Dat is schijnbaar de prijs die je betaald, als je zo'n ueber-1337 programmeur bent als ik.

Een beetje arrogant zijn is goed (vind zichzelf ook wel eens arrogant) maar hou er rekening mee dat andere mensen zich eraan ergeren en dat dit verder een discussie is.

[Zoijar]

Alarmnummer schreef op 08 augustus 2002 @ 14:14:
[...]
Er is nergens gedefinieerd bij de and operator dat hij altijd gaat optimaliseren.

Er is *per definitie* lazy evaluation zoals in de C++ standaard beschreven, daar is het dus gedefinieerd. Anders zou het "implementation specific" zijn. De C standaard zegt hetzelfde, Java naar mijn weten ook, Perl heb ik geen idee van, maar het zal wel. Dat is toch wel een groot deel van de talen. Natuurlijk kan je een taal schrijven waarbij het niet zo is. Je kan ook in assembler proggen, dan is je for/while lus niet eens correcte syntax Anyway...niet erg boeiend.

Over dat switch statement ben ik het trouwens helemaal met je eens. Meestal is er wel een pattern zodat je geen switch nodig hebt. Eigenlijk altijd...visitor, double dispatch, strategy...etc.

[Alarmnummer]

Zoijar schreef op 08 augustus 2002 @ 14:33:
Er is *per definitie* lazy evaluation zoals in de C++ standaard beschreven, daar is het dus gedefinieerd.

Ik zat met het systeem voor de RuG nog in gedachten Vandaar dat ik een beetje dwars lag.

Over dat switch statement ben ik het trouwens helemaal met je eens. Meestal is er wel een pattern zodat je geen switch nodig hebt. Eigenlijk altijd...visitor, double dispatch, strategy...etc.

Intussen gebruik ik veelvuldig het visitor design pattern om double dispatch voor elkaar te krijgen, en in het andere geval maak ik gebruik van polymorphisme om de juiste methode uitgevoerd te krijgen.

Maar de switch kan wel een handig zijn, en is ook veel overzichtelijker dan een reeks if else statements (en ook nog eens een stuk efficienter).

[Zoijar]

offtopic:
Het probleem met de standaard visitor zoals in DP-GoF is dat je een dependency aanlegt tussen al je classes. Ook is het erg lastig om nieuwe classes toe te voegen. Er zijn patterns voor double dispatch die dit probleem niet hebben. In modern C++ design (alexandrescu) staat er een goed hoofdstuk over. Misschien dat je het al wist trouwens, zei het alleen voor de volledigheid

Hoe meer er dwars gelegen wordt hoe beter...kritisch denken is altijd goed

[Alarmnummer]

Ten 1e heb ik meestal zelf de source ter beschikking dus ik heb niet zoveel last van nieuwe classes omdat die eenvoudig toe te voegen zijn. En verder bestaat er genoeg extensies op het visitor design pattern waarin het probleem van toevoegen van classes is opgelost, zie: dit : Element adder. Deze techniek is oa ook gebruikt in SableCC (de parser generator uit mijn signature). Maar verder is dit allemaal vrij offtopic

En die dependencies die vallen allemaal best wel mee. Ja kan eventueel gewoon een XXXVisitable interface maken, waardoor dit het het enige overeenkomstige hoeft te zijn tussen de classes. En heeft maak ik meestal een visitor voor een hierarchie voor objecten die op een of andere manier toch bij elkaar horen

Trouwens ik ben me op dit moment wat aan het verdiepen in Nice, en daarin zit oa multi dispatch. Aangezien dit naar java bytecode compileerd, kan ik dit ook gebruiken icm normale java code. En verder heb ik dan niet zoveel meer te maken met die visitors.

[TheOneLLama]

Soultaker schreef op 08 augustus 2002 @ 14:26:
[...]

Wordt er voor het doorvallen dan ook echt code uitgevoerd?

Bijvoorbeeld:

code:

switch (X)
{
  case A:
     doeIets;
  case B:
      enNogIets;
}

Of gebruik je het doorvallen alleen om in meerdere gevallen dezelfde code uit te voeren?

In het laatste geval ben ik met je eens dat het doorvallen een nuttige feature is (zie mijn reactie daarover), in het eerste geval niet.

In m'n code heb ik vaak dingen staan als bijvoorbeeld:

code:

switch(iets) {
  case A:
     doeietsExtra();
  case B:
  case C:
    doeiets();
    break;
  default:
    doedefaultiets();
  }

Het redelijk simpele (doch naar mij mening iets minder leesbare) if / else alternatief is in bytecode zo'n 10 bytes kleiner waarschijnlijk. Over snelheid durf ik niks te zeggen, maar aangezien de meeste code -> bytecode compilers dit met GOTO oplossen zou het tot resultaat kunnen hebben dat het net iets sneller is doordat er minder expressies geevalueerd moeten worden, maar dat is maar een gokje, ik leg me er niet op vast .
Uiteindelijk hangt het natuurlijk af van de verschillende manieren waarop geoptimaliseerd word (de if / else code doet *uiteindelijk* immers precies hetzelfde als de switch).

[Alarmnummer]

In java krijg je een table waarin je op case waarde kan springen, en dat is veel efficienter dan een reeks if else statements. Valt te vergelijken met zoeken door een lijst en door een hashmap.

Ik weet verder niet hoe dit bij andere talen is geimplementeerd, maar zal ook wel hetzelfde zijn.