[C++] Uit geneste for-loop "breaken"

[Tsjipmanz]

Ik doorloop een in 8 segmenten verdeelde 3 dimensionale dataset en probeer in elk van die segmenten een soort van seed-voxel te vinden. Hiervoor zijn een stuk of wat for-loops nodig. Op het moment dat er een dergelijk voxel is gevonden hoeft er niet verder gezocht te worden en wil ik omwille van de efficienty gelijk uit de for-lussen springen om door te gaan naar het volgende segment. Nu zit ik me af te vragen hoe dat zo fraai mogelijk kan.

Ik kan een boolean voxelFound bijhouden die van waarde verandert zodra het gewenste voxel is gevonden (dit stelde Janoz ook al voor). Echt fraai vind ik dit echter niet omdat ik de test op de waarde hiervan in 6 for-lussen moet inbouwen. C++ kent ook een goto statement wat in dit geval handiger is, maar voor niet-basic-programmeurs is goto toch redelijk not done.

Zijn hier nog mensen met suggesties?

[D2k]

ga voor de boolean
of als je exact wil weten waar ie stopt, gebruik dan exit codes

[whoami]

break springt uit slechts één loop. Goto zou ik zeker niet gebruiken.

Misschien is het handiger om gebruik te maken van een vlag die je zet als je uit één loop springt:

code:

for ()
{
  for ()
  {
      if ( gevonden)
      {
          break;
          Vlag = true;
      }
      if ( Vlag)
      { 
          break;
       }
  }
}

edit:
* whoami moet toch wat beter lezen.

[Reptile209]

Of, om de break van whoami te omzeilen:

C:

Vlag = false;
for (n=0; (n<x) && (!Vlag); n++)
{
  for (nn=0; (nn<xx) && (!Vlag); n++)
  {
     if (gevonden) 
       Vlag = true
     else
     {
        DoTheMagicThing(n, nn);
     }
  }
}

Oftewel: je for-loops kunnen de vlag ook al detecteren. Tip voor beide oplossingen: kondig het voortijdige einde van de loop aan in wat comments, over een paar maanden lees je er straal overheen!

[cameodski]

Kun je de verschillende segmenten niet in verschillende functies/methodes zetten? Op het moment dat er dan wat gevonden wordt, kun je met return gewoon je functie verlaten.

[Verwijderd]

Zoiets hoort toch gewoon met een WHILE loop, daar kun je makkelijk een conditie bij stoppen, die er voor zorgt dat je uit de loop springt.
Zonder gebruik te maken van zo'n klutzy exit ofzoo, en altijd sneller dan voor iedere loop een aparte methode aan-te-roepen.

[Alarmnummer]

[offtopic]
Ik zie dat veel meer mensen last hebben van onnodige enters. Wordt hier al iets aan gedaan?

[Tsjipmanz]

cameodski schreef op 03 oktober 2002 @ 11:33:
Kun je de verschillende segmenten niet in verschillende functies/methodes zetten? Op het moment dat er dan wat gevonden wordt, kun je met return gewoon je functie verlaten.

Dat had in principe ook wel gekund maar ik heb er voor gekozen dat niet te doen. Ik controleer nu toch maar in elke loop of de seedvoxel al gevonden is. Thanx y'all

[Zoijar]

ja bv zoiets als:

code:

bool findSeedVoxel(int& a, int& b) {
   for (int n=0; n<x; ++n) {
      for (int nn=0; nn<xx; ++nn) {
         if (gevonden) {
            a = x; b = xx;
            return true;
         }
      }
   }
   return false;
}

offtopic:
Marching cubes?

[D2k]

Alarmnummer schreef op 03 oktober 2002 @ 11:42:
[offtopic]
Ik zie dat veel meer mensen last hebben van onnodige enters. Wordt hier al iets aan gedaan?

[ook maar ff offtopic]
snap niet waar je het over hebt maar het kan nooit relevant zijn voor deze thread.

[cameodski]

Verwijderd schreef op 03 oktober 2002 @ 11:40:
Zoiets hoort toch gewoon met een WHILE loop, daar kun je makkelijk een conditie bij stoppen, die er voor zorgt dat je uit de loop springt.

Ook in een for loop kun je heel makkelijk een conditie toevoegen.

Zonder gebruik te maken van zo'n klutzy exit ofzoo, en altijd sneller dan voor iedere loop een aparte methode aan-te-roepen.

Hangt een beetje van de precieze situatie af, wat nu sneller is. En ook de optimizer kan ook nog een heleboel intelligente dingen doen.
Maar in principe heb je gelijk dat een methode aanroep voor extra overhead zorgt, maar of dat hier een probleem is? Ik zou het niet weten. Het ziet er in ieder geval wel fraaier uit, maar dat is natuurlijk mijn smaak.

[Alarmnummer]

Als je een for lus gaat gebruiken dan ging hij vroeger in het cx register de count zetten, en bij iedere iteratie gaat die automatisch 1 omlaag. Aangezien dit hardwarematig ondersteunt is, is dit denk ik het snelste. Ik weet verder niet wat de modernere c compilers doen, maar als het echt op snelheid aankomt, denk ik dat een for lus zonder extra condities icm een break het snelste is.

Maar vanuit het oogpunt van correctheid zou ik persoonlijk gaan voor while lussen ipv forlussen omdat je dus niet weet hoeveel iteraties je moet doen. Ik heb intussen al wel gemerkt dat dit een vrij persoonlijke smaak is, en ik ge/mis-bruik hier nu ook wel eens forlussen voor omdat je code overzichtelijker blijft.

[ook maar ff offtopic]
snap niet waar je het over hebt maar het kan nooit relevant zijn voor deze thread.

Als wat tussen code tags staat, heeft een onnodige regel wit ertussen. En de identatie die mist ook. (Dus geen lege ruimtes)

[Tsjipmanz]

Verwijderd schreef op 03 oktober 2002 @ 11:40:
Zoiets hoort toch gewoon met een WHILE loop, daar kun je makkelijk een conditie bij stoppen, die er voor zorgt dat je uit de loop springt.
Zonder gebruik te maken van zo'n klutzy exit ofzoo, en altijd sneller dan voor iedere loop een aparte methode aan-te-roepen.

Het probleem is niet zozeer uit een loop springen, dan wel het ineens uit meerdere geneste loops spingen. In feite is er niet zoveel verschil tussen WHILE en FOR maar bij het doorlopen van een 3D-array vind ik het mooier om FOR te gebruiken.

Voor de liefhebbers nog even de uiteindelijke implementatie:

C++:

   found=false;
    for (unsigned long k=zs ; k<ze && !found ; k++){
      for (unsigned long j=ys ; j<ye && !found; j++){
        for (unsigned long i=xs ; i<xe && !found; i++){
          if (mask.getVoxel(i,j,k)>0){
            int voxelvals=0;
            for (int mk=-1; mk<=2;mk++){
              for (int mj=-1; mj<=2 ;mj++){
                for (int mi=-1; mi<=2 ;mi++){
                  if (mask.inBounds(i+mi,j+mj,k+mk)){ voxelvals += ((mask.getVoxel(i+mi,j+mj,k+mk))>0);}
                }
              }
            }
            if (voxelvals==27){
              cout << "Seed voxel " << t << " found and set: " << i << "," << j << "," << k << endl;
              outp->putVoxel(i,j,k,255);
              found=true;
            }
          }
        }
     }
   }

[Zoijar]

zoiets?

register int c = 10;
do {
// blah
}
while (--c > 0);

Het schijnt ook zo te zijn dat in een for loop de ophoging ++i iha voor betere code zorgt dan i++, dit omdat er bij i++ de oude waarde wordt returned en er dus een temp copy nodig is. Beetje compiler ziet dat wel, maar misschien niet allemaal, en het kost weinig moeite.

[Alarmnummer]

Als het echt op snelheid aankomt, is het dan niet handiger om de counter variablen van de forlus buiten de forlussen te declareren? Het kan ook zijn dat de compiler dit al optimaliseerd. EN verder kan je mk+k,mj+j en mi+i ook veel efficienter berekenen. Mk+k en Mj+j kunnen in hun eigen lus al bepaald worden. En Mk+k, MJ+j en MI+i hoeft alleen de 1e keer berekend te worden, daarna kan gewoon een ++ uitgevoerd worden.

[Tsjipmanz]

Alarmnummer schreef op 03 oktober 2002 @ 11:55:
Als het echt op snelheid aankomt, is het dan niet handiger om de counter variablen van de forlus buiten de forlussen te declareren? Het kan ook zijn dat de compiler dit al optimaliseerd.

Hmm daar zeg je wat. Dat zou ik wel eens kunnen proberen idd.

[Alarmnummer]

Je zou er trouwens ook voor kunnen kiezen om die binnenste 3 forlussen (die eigelijk 9 iteraties pakken) volledig te unrollen.


*moet weer denken aan zijn X-mode tijdperk.. 320x200@16bits* woei.. wat was ik blij met een 32 bits pageflip

en wat was 64k nog een berg geheugen

*voelt zich nu echt een oude man*

[Verwijderd]

In de binnenste loop ben je 27 gevallen aan het testen of die aan bepaalde eisen voldoen. En daarna doe je iets als alle gevallen kloppen ,maar je stopt niet als 1 van die gevallen niet voldoet, dat is nogal inefficient voor een stuk code dat al binnen 3 for loops staat.
Dus het beste kun je de binnenste loops unrollen tot een lange if met veel &&s.
En misschien kun je ook nog inBounds en getMask functies combineren tot 1 boolean fuctie, scheelt ook weer overhead.

[Soultaker]

Alarmnummer schreef op 03 oktober 2002 @ 11:48:Als wat tussen code tags staat, heeft een onnodige regel wit ertussen. En de identatie die mist ook. (Dus geen lege ruimtes)

offtopic:
Bij Gecko-based browsers ontbreken juist alle lege regels in code. Dit zou, volgens die prutsers die Parse ontwikkeld hebben, liggen aan een bug in de Gecko-engine waardoor de "display:inline" style niet goed afgehandeld wordt. Het commentaar van chem was dat we maar bij Mozilla moesten gaan zeuren.

Gebruik je toevallig Internet Explorer? In dat geval is er misschien een kans dat de heren het probleem waardig genoeg vinden om het op te lossen. (Wat natuurlijk niet vanzelfsprekend is, als jouw webbased product niet werkt in combinatie met een gangbare browser.)

Ik propageer breaks zelf vaak door te checken of een lus volledig was uitgevoerd; zoiets dus:

C:

int x, y;
for(x = 0; x < 10; ++x)
{
    for(y = 0; y < 10; ++y)
    {
        /* doe iets */
        if(/*iets*/) break;
        /* doe iets */
    }
    if(y < 10) break;  /* <-- propageer break */
}

Het effect is hetzelfde als het gebruik van de break-variabele, met het verschil dat je geen extra variabele hoeft te introduceren en wijzigen. Nadeel is misschien dat het if-statement niet voor zichzelf spreekt, maar ik gebruik deze constructie zelf dusdanig vaag, dat ik 'm meestal wel direct herken.

In Java kun je gewoon labels plaatsen voor lussen en daar naar toe breaken. Het gebruik van labels staat op zich niet zo mooi (het doet vaak aan goto denken) maar in de praktijk werkt het wel erg handig.

[Soultaker]

Als je overbodige checks wilt voorkomen, kun je natuurlijk ook in een enkele for-lus beide variabelen behandelen:

C:

int x, y;
for(x=0, y=0; y<5; ++x==8?x=0||++y:1)
    printf("%i %i\n", x, y);

[Tsjipmanz]

Zoijar schreef op 03 oktober 2002 @ 11:43:

offtopic:
Marching cubes?

Nee, ik verfijn en verbeter de segmentatie van een binaire medische dataset door middel van conditionele dilaties. Met meerdere seed-voxels van waaruit begonnen wordt zijn er een stuk minder iteraties nodig, wat zeker scheelt op datasets van 256^3

[Verwijderd]

Je kunt natuurlijk ook try-catch misbruiken

C++:

try {
  for(..) {
    for(..) {
      for(..) {
        if(position == found) throw position;
      }
    }
  }
}
catch(Coordinates pos) {
  std::cout << "Found at " << pos << std::endl;
}

[curry684]

Verwijderd schreef op 03 oktober 2002 @ 13:46:
Je kunt natuurlijk ook try-catch misbruiken

Gatver!!!

_{maar wel handig op z'n tijd idd}

[.oisyn]

Verwijderd schreef op 03 oktober 2002 @ 13:46:
Je kunt natuurlijk ook try-catch misbruiken

C++:

try {
  for(..) {
    for(..) {
      for(..) {
        if(position == found) throw position;
      }
    }
  }
}
catch(Coordinates pos) {
  std::cout << "Found at " << pos << std::endl;
}

ik geloof dat het woord 'performance' al eens is gevallen in deze thread

ik pleit zelf trouwens voor een extra parameter voor de break of continue statements, namelijk het aantal loops dat je moet doorbreken. Maar goed, ik denk dat de compiler het met gebruik van een boolean al aardig kan optimaliseren. En zo niet: scheit aan de 'standaard mening' en gebruik goto

[MisterData]

Volgens mij is het (in Java in ieder geval wel dacht ik) mogelijk om een label achter een for-declaratie te zetten en dan in een geneste for loop iets als "break buiten;" te doen (als de eerste loop label "buiten" heeft) Ik zal het nog es opzoeken in m'n grote Java-boek. Want als het in de Java-grammatica zit, dan kan C++ het vast ook wel.

[MisterData]

Het Java-boek geeft het volgende voorbeeld:

C:

buiten: for(int buiten_index=0;buiten_index < array.length; buiten_index++) {
  binnen : for(int binnen_index=0;binnen_index < array[buiten_index].lenth;binnen_index++)  {
    if(binnen_index==4) {
      break buiten;
  }
}
}

[Alarmnummer]

Hmmzz... ik denk dat een aantal mensen in deze thread gemarkeerd moeten worden als extreem gevaarlijk

[MisterData]

Alarmnummer schreef op 03 oktober 2002 @ 17:06:
Hmmzz... ik denk dat een aantal mensen in deze thread gemarkeerd moeten worden als extreem gevaarlijk

Maar je krijgt toch veel schonere code als je die break-dingen toepast? Allerlei flags bijhouden lijkt me niet echt handig enzo

[Verwijderd]

.oisyn schreef op 03 oktober 2002 @ 16:47:
En zo niet: scheit aan de 'standaard mening' en gebruik goto

Jij bent liev! .

Ik roep dit zo vaak, maar goto is slechts vies omdat men denkt dat het vies is. Goto is niet vies. Een goede programmeur weet wanneer goto handig is en wanneer niet. En dan mag ik nog zo'n pruts0r zijn, ik gebruik goto hier en daar en dat scheelt me een enorm aantal extra booleans die de code extra onleesbaar maken.

Oftewel: gebruik goto. .

[Zoijar]

Hier kan ik alleen om lachen...eigenlijk huilen

[Reptile209]

In boeken zie je bij Goto vaak:
Een "vies" statement dat voor zeer onduidelijke code kan zorgen. Een Goto kan vrijwel altijd op een andere manier worden opgelost.

Maar misschien... heel misschien... is dit een (de? ) uitzondering die de regel bevestigt. Het _kan_ idd anders ('k heb nu al 4-5 alternatieven gezien), maar het wordt er zo hier en daar niet leesbaarder van. Een goto met, op de plaats waar naar toegesprongen wordt, adequate documentatie zou hier eventueel misschien een mogelijkheid kunnen zijn

[Alarmnummer]

Ik denk dat micro optimalisaties en readability vaak elkaars antecedenten zijn.

Een goeie regel voor microoptimalisatie is dan ook: doe het niet Maar in jouw geval is het dusdandig belangrijk dat je hele applicatie ervan af hangt. Ik denk dat je dan al snel op code uitkomt waarbij Janoz zijn sig van toepassing is

[CyberSnooP]

Ik heb vandaag, voor het eerst in jaaren.. oké "ON ERROR GOTO" daar gelaten, ook een goto gebruikt. Die dingen worden overal afgeraden en volkomen terecht aangezien je bijna alles door het checken / zetten van een boolean kunt oplossen wat vaak een stuk mooier is.
Alleen in het geval van kritieke performance is ie best nuttig te gebruiken en als je het mij vraagt zou het hier evt. ook mogen.

Bedenk echter wel dat de winst die je hier mee haalt miniem is en de viesheid die je code wint maximaal

[MSalters]

curry684 schreef op 03 oktober 2002 @ 14:04:
[...]

Gatver!!!

_{maar wel handig op z'n tijd idd}

Dat viel nog wel mee hoor.
Selectief uit N loops breken:

code:

void foo( X& x )
{
  for ( ;; )
  { 
     try
    {
       ..
      foo( x ); 
      if (x.bar() ) throw 5; // break 5 recursions
      ..
    }
    catch ( int N )
    {
      if (N>0) throw N-1;
    }
  }
}

[Alarmnummer]

*plaatst MSalters boven aan zijn lijstje*

[Janoz]

Alarmnummer schreef op 03 oktober 2002 @ 12:07:
Je zou er trouwens ook voor kunnen kiezen om die binnenste 3 forlussen (die eigelijk 9 iteraties pakken) volledig te unrollen.

We gebruiken -unrollloops als compiler optie. Dus dat doet de GNU compiler al voor ons

[.oisyn]

MSalters schreef op 03 oktober 2002 @ 23:44:
[...]

Dat viel nog wel mee hoor.
Selectief uit N loops breken:

code:

void foo( X& x )
{
  for ( ;; )
  { 
     try
    {
       ..
      foo( x ); 
      if (x.bar() ) throw 5; // break 5 recursions
      ..
    }
    catch ( int N )
    {
      if (N>0) throw N-1;
    }
  }
}

en toen kreeg je een stack overflow

[Alarmnummer]

Janoz schreef op 04 oktober 2002 @ 00:49:
We gebruiken -unrollloops als compiler optie. Dus dat doet de GNU compiler al voor ons

Maar kan de compiler zo perfect van de situaties uitgaan zoals jij dat kan?

[Janoz]

Alarmnummer schreef op 04 oktober 2002 @ 01:04:
[...]

Maar kan de compiler zo perfect van de situaties uitgaan zoals jij dat kan?

De compiler is iig beter in het lezen van code. En aangezien ik het vaak voor mijzelf ook wat leesbaar wil houden gok ik het er maar op .

[Verwijderd]

Alarmnummer schreef op 03 oktober 2002 @ 11:48:
Als je een for lus gaat gebruiken dan ging hij vroeger in het cx register de count zetten, en bij iedere iteratie ...

/enigszins offtopic:
Welk cx-register? Denk jij dat er alleen maar Ix86 processors bestaan?

[Alarmnummer]

Verwijderd schreef op 04 oktober 2002 @ 12:44:
[...]
/enigszins offtopic:
Welk cx-register? Denk jij dat er alleen maar Ix86 processors bestaan?

Vergeef me, ik dacht echt dat er alleen maar x86 processoren waren Maar wou ermee duidelijk maken dat je ook hardwarematige optimalisaties kan uitvoeren als je weet op welke architectuur je draait. En verder, wou draait er nou niet op een x86?? een paar gekke mekkers en misschien nog een paar van die rare amiga pipo`s (was er vroeger ook een), maar face it: alle thuiscomputers zijn tegenwoordig x86

[whoami]

Alarmnummer schreef op 04 oktober 2002 @ 13:40:
[...]

Vergeef me, ik dacht echt dat er alleen maar x86 processoren waren Maar wou ermee duidelijk maken dat je ook hardwarematige optimalisaties kan uitvoeren als je weet op welke architectuur je draait.

Oeh, en dat zegt een Javahova.

[Alarmnummer]

whoami schreef op 04 oktober 2002 @ 13:41:
Oeh, en dat zegt een Javahova.

Maar dat wil niet zeggen dat me daar nooit mee bezig heb gehouden Vroeger (jaja.. vroeger) ben ik veel bezig geweest met pascal/c/asm. En daar probeerde je ook alles eruit te krijgen als je met graphics bezig was, anders draaide het niet snel genoeg

Maar ik ben nu verder ontwikkeld, ik hou me niet meer met dat soort aardse zaken bezig

[Verwijderd]

Alarmnummer schreef op 04 oktober 2002 @ 13:40:
[...]
En verder, wou draait er nou niet op een x86??

Mwah, als ik hier even naast me kijk zie ik daar een testruimte waar een hele rij DEC servers staat. Vertel mij niet dat daar x86 in zit...

van een paar gekke mekkers en misschien nog een paar van die rare amiga pipo`s (was er vroeger ook een), maar face it: alle thuiscomputers zijn tegenwoordig x86

Wie zei er dan dat de topicstarter voor een thuiscomputer aan het proggen was?

[Alarmnummer]

Verwijderd schreef op 04 oktober 2002 @ 15:21:
Mwah, als ik hier even naast me kijk zie ik daar een testruimte waar een hele rij DEC servers staat. Vertel mij niet dat daar x86 in zit...

Ik heb beneden ook nog een oude sparcstation staan. Maar desktop-kant is tegenwoordig bijna allemaal x86

Wie zei er dan dat de topicstarter voor een thuiscomputer aan het proggen was?

Lijkt me toch wel erg voor de hand liggend, vind je niet?

En verder lijkt met ook niet erg interessant om hier een hele discussie over te voeren, dus ik geef jou het laatste woord