[C++] for statement, return

[Kaastosti]

Ik heb een nieuw 'probleem' weten te creëren. Ik ben bezig met een opdracht van school, waarbij ik priemgetallen moet berekenen. Gezien het verdere verloop van de opdracht is het het handigst om eerst een aantal (zeg 10000) priemgetallen op te slaan in een vector. Dat mag het probleem niet zijn. Wat wèl het probleem is, is de manier waarop ik ze er in wil krijgen. Hier onder de code die ik daarvoor wil gebruiken:

code:

void Controle::maakRij(){
        int j=0;
        for(invoer=1;invoer<100;invoer++){
                for(int i=2;i<invoer;i++){
                if(invoer%i<=0){}
                        else{
                                priemRij[j]=invoer;
                                j++;
                        }
                }
        }
}

Het probleem is, dat op het moment dat een priemgetal gevonden wordt er niet meteen naar de volgende invoer wordt gegaan, maar verder wordt getest met andere delingen met i. Hierdoor komt de lijst (van nu 10 waarden) er uit te zien als 3 4 5 5 5 6 6 7 7 7.

Het probleem is opgelost als ik zowel bij het ontdekken van een niet-priemgetal als bij een priemgetal de opdracht kan geven deze lus te onderbreken en verder te gaan met de volgende invoer. Als ik een return invoer, wordt meteen alles onderbroken en wordt de vector opgevuld met 0-waarden. Hoe kan ik iets dergelijks toch >>simpel<< bereiken?

[ACM]

zoek es naar break en/of continue

verder kan je de deling van priem alle even getallen behalve 2 overslaan en zal een restwaarde (bij je % ) nooit kleiner dan 0 zijn, dus daar hoef je niet op te testen.
Een lege if is ook niet zo netjes.

Zoek es op priem algoritmes, er zijn er legio van geschreven.

[Verwijderd]

-edit-
eigenlijk is het ook leuker als je dit zelf uitzoekt - maar zoek eens op 'break' enzo. .

[Kaastosti]

Aaargh break dat was het commando wat ik zocht
ACM.. ik weet het.. het is allemaal niet zo netjes. Wat je ook nog kan doen is alleen de sqrt(invoer) delen door i. Boven de wortel zit je namelijk al dubbel te tellen
Maar dat maakt op dit punt nog niet echt uit. Eerst werken, dan code netjes fixxen
Bedankt voor de hulp!

[Alarmnummer]

Ieks een break Een forlus gebruik je als het itteraties bekend is, en een while lus in het andere geval. Dit zijn in ieder geval de regels die ik heb geleerd en ook altijd nog toepas Ik zou echt gaan voor een while lus *voelt nu een hele flame opleven*

[.oisyn]

Je algoritme is idd fout. Of tenminste je code die dat algoritme moet presenteren

Wanneer is een getal geen priem? Als het het exact 2 delers heeft (1 en zichzelf).
De simpelste (en langzaamste) manier is idd gewoon proberen te delen zoals jij doet. Alleen pas als je alle delers hebt gehad en geneen kwam eruit met rest 0, dan is ie priem. Je kunt dus pas een priem toevoegen nadat je alle delers hebt geprobeerd, dus na de binnenste for-lus (en niet erin, zoals je nu doet)

het moet dus zo (de binnenste lus):

code:

bool isPriem = true;
for (int i = 2; i < invoer; i++)
{
    if (invoer % i == 0)    // invoer is deelbaar door i
    {
        isPriem = false;     // dus geen priem
        break;                   // en stop de loop aangezien een deler is gevonden
    }
}

if (isPriem)
    priemRij[j++] = invoer;

overigens kun je, zoals ACM al zei, alle even getallen behalve 2 overslaan, en je hoeft ook maar te controleren tot de wortel van invoer

[.oisyn]

Alarmnummer schreef op 07 augustus 2002 @ 17:26:
Ieks een break Een forlus gebruik je als het itteraties bekend is, en een while lus in het andere geval. Dit zijn in ieder geval de regels die ik heb geleerd en ook altijd nog toepas Ik zou echt gaan voor een while lus *voelt nu een hele flame opleven*

dat vind ik echt onzin. Ik gebruik een for-lus als er na elke iteratie iets gedaan moet worden (meestal een variabele met 1 verhogen), zodat je continue kan gebruiken om de huidige iteratie af te breken en toch nog die actie uit te voeren, iets wat met while niet mogelijk is zonder hele if-constructies te maken die het zaakje onleesbaar maken

[Alarmnummer]

Schijnbaar zijn mensen hier door de loop van de tijd anders over gaan denken. En ik ben het met je eens dat de code er niet altijd beter op wordt. Maar ik pas het zelf altijd toe, en heb er zelf nog nooit problemen mee gehad. Ik keur het trouwens ook af van stagaires die bij ons stage lopen. *is grote zeurkous*

[ps]
door breaks en continue`s te gebruiken wordt je programmaflow minder leesbaar in mijn ogen. Ik keur dan ook ieder gebruik van een break of continue in java af. (alleen mag hij gebruikt worden de slecht ontworpen waterval switch case statement).

[Verwijderd]

Alarmnummer schreef op 07 augustus 2002 @ 17:26:
Ieks een break Een forlus gebruik je als het itteraties bekend is, en een while lus in het andere geval. Dit zijn in ieder geval de regels die ik heb geleerd en ook altijd nog toepas Ik zou echt gaan voor een while lus *voelt nu een hele flame opleven*

Hm, ik leerde dat een forlus is als je een begin+eind stadium hebt met een regelmatige bewerking op een of meer van de argumenten per cycle in de loop. En dat is hier het geval. Break gebruik je dan als je eerder dan verwacht er alsnog uitmoet. Maar omdat je ook een 'zeker' eindpunt hebt (i==invoer) mag je hier dus for gebruiken.

Of ben jij ook zo'n ultra-clean programmer die vind dat functies een (1) return statement horen te hebben en breaks alleen zijn toegestaan in een switch? . /me voelt een goto flamewar opborrelen.

Lekker offtopic. .

[.oisyn]

maar als de code er niet beter van wordt, waarom doe je het dan?

ik ben denk ik gewoon niet zo'n purist als jij bent, het gaat mij meer om het doel, niet hoe ik dat doel bereik (zolang mijn code maar leesbaar is)

[.oisyn]

Alarmnummer schreef op 07 augustus 2002 @ 17:31:
door breaks en continue`s te gebruiken wordt je programmaflow minder leesbaar in mijn ogen.

daar ben ik het niet mee eens. Als je goed indenteerd kun je makkelijk de lussen herkennen, en dus kun je gelijk zien waar de break of continue 'heen wijst'. Dat is in een ingewikkelde geneste if-constructie minder goed te zien

[Alarmnummer]

Verwijderd schreef op 07 augustus 2002 @ 17:34:
Hm, ik leerde dat een forlus is als je een begin+eind stadium hebt met een regelmatige bewerking op een of meer van de argumenten per cycle in de loop. En dat is hier het geval.

Ik ben het 100% met je eens dat je het moet gebruiken bij een vast begin en eind stadium, en dat heb je hier dus niet. Het kan gebeuren dat hij eerder uit een forlus stapt.

Of ben jij ook zo'n ultra-clean programmer die vind dat functies een (1) return statement horen te hebben en breaks alleen zijn toegestaan in een switch? .

Ik vind dat de switch case helemaal geen break nodig zou hebben als je niet dat stomme waterval effect zou krijgen. Dus ik ben 100% tegen break

Ik vind trouwens 1 return statement weer 1 te ver gaan, omdat ik een functie uitwil zo gauw dat kan. Maar ik ben tegen return statements in dieper geneste constructies omdat je snel het overzicht verliest. Het gebeurd trouwens niet meer zo vaak dat ik van die lappers heb, en dan valt alles wel te overzien. Het ligt denk ik ook heel erg aan de taal waarin je werkt.

Lekker offtopic. .

Tis zomervakantie, en dat mag dat

[.oisyn]

Alarmnummer schreef op 07 augustus 2002 @ 17:38:
Tis zomervakantie, en dat mag dat

* houdt de hand op de ban-knop *

[Alarmnummer]

.oisyn schreef op 07 augustus 2002 @ 17:34:
maar als de code er niet beter van wordt, waarom doe je het dan?

Omdat de flow van je routine (in mijn ogen) verloren gaat bij het gebruik van breaks en continue`s, het 'whilen' is dus de minste van de 2 kwaden. In java is het trouwens ook vrij ongebruikelijk om dit te gebruiken, en gelukkig zie je het ook niet veel.

ik ben denk ik gewoon niet zo'n purist als jij bent, het gaat mij meer om het doel, niet hoe ik dat doel bereik (zolang mijn code maar leesbaar is)

Eigelijk zijn routines intussen redelijk bijzaak geworden. Ik ben eigelijk meer bezig met object ontwerp en algoritmes. En routine schrijven (op basis van een algoritme) is niet meer zo`n probleem.

* houdt de hand op de ban-knop *

ach.. misschien gaat het nivo dan ook meteen iets omhoog

[Kaastosti]

Sorry dat ik deze zeer verhitte discussie even onderbreek...
Ik heb de code nu gewijzigd en deze werkt al iets beter. Ik houdt echt een probleem. Getallen 2 en 3 worden in de vector gezet. Verder wordt deze opgevuld met 0-waarden.
Het rare is dat, als ik op het scherm laat zetten welke waarden GEEN priem zijn, bijvoorbeeld 11 daar (logischerwijs) niet bij zit. Dit houdt in dat 11 wel in de vector opgenomen zou moeten worden. Dat gebeurt dus niet. Hier de huidige code:

code:

void Controle::maakRij(){
        priem=true;
        int j=0;
        for (invoer=2;invoer<100;invoer++){
                for (int i = 2; i < invoer; i++){
                        if (invoer % i == 0){
                                cout<<invoer<<" "<<i<<endl;
                                priem = false;
                                break;
                        }
                }
                if(priem==true){
                        cout<<invoer<<"-------------"<<endl;
                        priemRij[j] = invoer;
                        j++;
                }
        }
}

...om de discussie weer ff on-topic te krijgen

[Alarmnummer]

Je hebt je priem = true te hoog staan, moet in de 1e for lust staan.

Je kan trouwens ook betere een aparte functie maken of een bepaald getal priem is.

code:

for(int invoer = 0;invoer<100;invoer++){
    if(isPriem(invoer)){
         ...afdrukken.
    }
}

Je had dan dit probleem ook niet gehad, omdat alle relevante dingen beetje bij elkaar staan. Wat jij doet kan je beetje vergelijken met het programmeren mbv globale variablen.

[Kaastosti]

daaamn *need brain*... die was iets te simpel he

[.oisyn]

je moet priem weer op true zetten bij elke invoer, anders zodra ie op false staat (bij 4), wordt de rest ook als false afgehandeld

.mental note: sneller reageren

[ACM]

Priem detecteren met een while is trouwens nog niet eens zo heel moeilijk.

iets ala:

code:

isPriem = false;
while(!isPriem && etc)
{
    // doe je delingen voor de test op priem
    if(priem)
    isPriem = true;
}

Scheelt je weer een break
En beter gebruik van while, omdat je van te voren niet perse weet hoever ie gaat.

[Alarmnummer]

[offtopic]
Kan je trouwens in c++ ook ter plekke een variable declareren of moet dat nog steeds in het begin van de methode?

code:

if(...){
   int a = ....
}

[.oisyn]

ACM: stfu

Alarmnummer schreef op 07 augustus 2002 @ 17:50:
[offtopic]
Kan je trouwens in c++ ook ter plekke een variable declareren of moet dat nog steeds in het begin van de methode?

code:

if(...){
   int a = ....
}

natuurlijk kan dat
ook dat heeft java 'geleend' van C++

[Kaastosti]

Ik zou er inderdaad een aparte functie voor kunnne maken, maar uiteindelijk wil ik ze niet op het scherm zetten. Dat is nu alleen even ter controle of het werk. Ik ga met alle waarden in de vector nog berekeningen uitvoeren. Na invoer van een getal moet het programma weergeven of het priem is of niet (vergelijken met waarden in de vector), het voorliggende en nakomende priemgetal weergeven en als laatste de theorie van Golbach testen:
Alle positieve even getallen zijn opgebouwd uit 2 priemgetallen... ook dat is makkelijker met een vector ipv steeds opnieuw alles laten berekenen

[Alarmnummer]

Java heeft het meeste van c++ geleend en dat is ook niet erg. Java is voor mij op dit moment de meest handige taal in te programmeren voor wat ik wil En er zijn veel tools voor uit die erg interessant zijn. Maar zo gauw zich iets beters voordoet dan ga ik daarop over (ben op dit moment beetje verliefd aan het worden op Nice).

regel:
een it`er kent geen loyaliteit tov software.

[Alarmnummer]

Trouwens misschien is het handiger als je een betere zoekstructuur gaat gebruiken ipv een lijst. In een lijst zul je toch gemiddeld n/2 keer moeten zoeken. In een tree moet je log(n) keer zoeken en in een hashtable zul je daar altijd een constante tijd voor nodig zijn. Ik zou echt gaan voor een hashtable.

[Kaastosti]

Mijn programmeerskillz zijn van een aard om echt trots op te zijn. Ik vond het al heel briljant om het in een vector te dumpen

[.oisyn]

Ratch schreef op 07 augustus 2002 @ 18:05:
Mijn programmeerskillz zijn van een aard om echt trots op te zijn. Ik vond het al heel briljant om het in een vector te dumpen

gebruik dan std::vector

[Kaastosti]

Eeeeh even een uitdrukking van briljantie:
'HUH?'
Leg uit

[.oisyn]

dan kun je beter gewoon de documentatie erbij pakken

vector is een standaard C++ klasse in de STL (Standard Template Library)
Het is een klasse waarin je elementen toe kunt voegen en verwijderen, en het regelt zelf de geheugen allocatie enzo. Verder kun je het ook gewoon benaderen als array

code:

#include <iostream>
#include <vector>

int main ()
{
    std::vector<int> v;
    for (int i = 0; i < 100; i++)
        v.push_back (i);

    for (int i = 0; i < v.size (); i++)
        std::cout << v[i] << std::endl;
}

[Kaastosti]

Aaaah ik snap wat je bedoelt... inderdaad... dat werkt beter

[Verwijderd]

Alarmnummer schreef op 07 augustus 2002 @ 17:50:
[offtopic]
Kan je trouwens in c++ ook ter plekke een variable declareren of moet dat nog steeds in het begin van de methode?

code:

if(...){
   int a = ....
}

Niet alleen declareren, je moet em daar tevens definieren. Persoonlijk vind ik deze constructie in C++ echter te beperkt om echt algemeen bruikbaar te kunnen zijn. Zie hiervoor mijn topic van twee maandjes geleden: [rml][ c++] if (T a = b) ... <= deze feature te beperkt?[/rml].

[MSalters]

Ratch schreef op 07 augustus 2002 @ 18:05:
Mijn programmeerskillz zijn van een aard om echt trots op te zijn. Ik vond het al heel briljant om het in een vector te dumpen

... en dan miste je push_back() ook nog

* MSalters loopt nu echt naar de goeie smiley te zoeken

[.oisyn]

MSalters schreef op 07 augustus 2002 @ 23:08:
[...]
... en dan miste je push_back() ook nog

* MSalters loopt nu echt naar de goeie smiley te zoeken

maar wie zegt dat hij gebruik maakte van std::vector ?
imho had hij het alleen over een vector als in een array (wat in principe ook een vector is)

[Kaastosti]

Yup... simpelweg een grote rij getallen die even opgeslagen moet worden... niets anders dan een array eigenlijk. Alleen kan je de grootte van de vector tijdens het invoegen van gegevens veranderen en heeft een vector meer leuke mogelijkheden dan een primitief array. Jaja... ik heb sommige dingen van de programmeerlessen nog wel onthouden

[.oisyn]

aha, maar je gebruikte dus geen primitieve array, of wel?
zo niet, wat gebruikte je dan?

[Kaastosti]

dat was dus die vector

[Verwijderd]

Alarmnummer schreef op 07 augustus 2002 @ 17:31:
Schijnbaar zijn mensen hier door de loop van de tijd anders over gaan denken. En ik ben het met je eens dat de code er niet altijd beter op wordt. Maar ik pas het zelf altijd toe, en heb er zelf nog nooit problemen mee gehad. Ik keur het trouwens ook af van stagaires die bij ons stage lopen. *is grote zeurkous*

Gelukkig heb ik dan niet jouw als begeleider gehad...

[Alarmnummer]

Ik denk omdat het komt dat jij c(++) progger bent en ik java progger. In java is het vrij ongebruikelijk om met breaks en continue`s de programmaflow te gaan bepalen. Ik merk aan jullie antwoorden op dat het met c++ dus niet zo is, maar ik hierboven de argumenten gegeven waarom die elementen om mij part zelfs uit de taal weggelaten hadden kunnen worden.

[.oisyn]

Ratch schreef op 08 augustus 2002 @ 04:06:
dat was dus die vector

ah oeps dan begreep ik je dus totaal verkeerd

[Olaf van der Spek]

.oisyn schreef op 07 augustus 2002 @ 17:29:
[...]

dat vind ik echt onzin. Ik gebruik een for-lus als er na elke iteratie iets gedaan moet worden (meestal een variabele met 1 verhogen), zodat je continue kan gebruiken om de huidige iteratie af te breken en toch nog die actie uit te voeren, iets wat met while niet mogelijk is zonder hele if-constructies te maken die het zaakje onleesbaar maken

Dan zou je toch

code:

do
{
}
while (1)

kunnen gebruiken?

[Olaf van der Spek]

Alarmnummer schreef op 07 augustus 2002 @ 17:58:
Trouwens misschien is het handiger als je een betere zoekstructuur gaat gebruiken ipv een lijst. In een lijst zul je toch gemiddeld n/2 keer moeten zoeken. In een tree moet je log(n) keer zoeken en in een hashtable zul je daar altijd een constante tijd voor nodig zijn. Ik zou echt gaan voor een hashtable.

Ik zou in dit geval voor een array gaan, dan heb je maar 1-bit per entry nodig.

Verder zou je ook het algorithme zelf kunnen verbeteren.

[Alarmnummer]

Als je veel moet zoeken, wat zou dan het efficientste zijn? En ik vind 1 bit per entry wel erg weinig om een priemgetal anders dan 1 in te stoppen

[Olaf van der Spek]

Ik weet niet precies hoeveel priemgetallen er zijn in het domein dat je wilt opslaan, maar met 1-bit sla je dus op of dat getal priem is. Het getal zelf hoef je niet op te slaan. Als > 1/16 priem is kost dit de minste ruimte als je tot 64 - 128 kb gaat.

[Alarmnummer]

Ik snap al wat je bedoelt. Ik dacht dat je in die array een priemgetal wou zetten.
dus [1,2,3,5,7....]

Ik denk trouwens dat jouw manier uiteindelijk erg inefficient gaat worden qua opslagruimte. Verder kun je er wel erg snel door zoeken.

bool isPrim = priemlist[getal]

[Olaf van der Spek]

Ok. Als je zo'n array gaat gebruiken kun je hem namelijk ook veel sneller vullen (zonder deling).

[Alarmnummer]

Het zou trouwens al 50% besparen als je automatisch alle even elementen weghaald. Dus

code:

if (getal = 2)
    isPriem = true;
else
   isPriem = priemArray[priem/2];

[Olaf van der Spek]

Daar zou ik toch even == van maken.

[MisterData]

.oisyn schreef op 07 augustus 2002 @ 17:34:
maar als de code er niet beter van wordt, waarom doe je het dan?

ik ben denk ik gewoon niet zo'n purist als jij bent, het gaat mij meer om het doel, niet hoe ik dat doel bereik (zolang mijn code maar leesbaar is)

Inderdaad Volgens mij is break ook nog sneller dan een variabele bijhouden en die telkens checken

[ Voor 0% gewijzigd door MisterData op 08-08-2002 17:54 . Reden: denk dat ik maar es een typecursus moet gaan doen :( ]

[Alarmnummer]

OlafvdSpek schreef op 08 augustus 2002 @ 17:51:
Daar zou ik toch even == van maken.

Ach.. bij mij is gewoon alles een priemgetal

[Alarmnummer]

MisterData schreef op 08 augustus 2002 @ 17:54:
[...]

Inderdaad Volgens mij is break ook nog sneller dan een variabele bijhouden en die telkens checken

Als een break statement slecht is, dan vind ik snelheid een slecht argument om hem te verkiezen boven een conditie.

[Olaf van der Spek]

Alarmnummer schreef op 08 augustus 2002 @ 17:58:
[...]
Ach.. bij mij is gewoon alles een priemgetal

Dan kun je de rest ook wel weg-optimizen.

[Zoijar]

Heb niet het hele draadje gelezen, maar ik heb ooit dit moeten maken voor "school"...misschien handig? Geen idee... Moest toen zelf een Set schrijven ook, maar die kan je vervangen door std::set

code:

typedef fasmit::set<int> SET;

SET createPrimeSet(int upperbound) {
        SET p;
        for (int q=2; q<=upperbound; ++q) {
            p.store(q);
        }

        for (int i=2; i <= upperbound / 2; ++i) {
            for (int j=2; j <= upperbound / i; ++j) {
                if (i*j <= upperbound) p.remove(i*j);
            }
        }
    
        return p;
}

[.oisyn]

Alarmnummer schreef op 08 augustus 2002 @ 17:59:
[...]
Als een break statement slecht is, dan vind ik snelheid een slecht argument om hem te verkiezen boven een conditie.

hangt er maar net vanaf wat voor applicatie je aan het ontwikkelen bent. Bij een GUI gevalletje dat een een of ander lusje nodig heeft maakt het niet echt uit, maar als je een key-cruncher oid aan het schrijven bent is snelheid echt wel belangrijker dan hoe elegant je code er volgens jou uitziet (mijn eigen definitie van elegantie is snel en doelmatig, met weinig code... maar ik ben vooral met computer graphics bezig )

OlafvdSpek schreef op 08 augustus 2002 @ 17:15:
[...]
Dan zou je toch

code:

do
{
}
while (1)

kunnen gebruiken?

nou het gaat me erom dat het 3e element uit een for-lus niet in een while past

code:

for (a; b; c)
{
    ...
}

is te schrijven als

code:

a;
while (b)
{
    ...
    c;
}

echter, als ik in de for lus ergens een continue statement heb staan, gaat ie door naar de volgende iteratie, maar eerst voert ie c nog uit. Bij een while-lus wordt dat gewoon overgeslagen, waardoor je met if-constructies ervoor moet zorgen dat ie toch nog uitgevoerd wordt (duur dus gewoon geen continue te gebruiken). Je kunt natuurlijk ook wel die c zetten voor elke continue, maar persoonlijk vind ik dat nog lelijker

[Alarmnummer]

.oisyn schreef op 08 augustus 2002 @ 23:23:
[...]

hangt er maar net vanaf wat voor applicatie je aan het ontwikkelen bent. Bij een GUI gevalletje dat een een of ander lusje nodig heeft maakt het niet echt uit, maar als je een key-cruncher oid aan het schrijven bent is snelheid echt wel belangrijker dan hoe elegant je code er volgens jou uitziet (mijn eigen definitie van elegantie is snel en doelmatig, met weinig code... maar ik ben vooral met computer graphics bezig )

Bij mij is correct code de juiste techniek voor de juiste job. Ik ben me aan het verdiepen in allerlei design patterns die voornamelijk betrekking hebben tot het ontkoppelen van info methodes aan model objecten. Hierdoor schrijf je soms wat langzamere code, maar ik schrijf het met een bepaald oplosmechanisme voor ogen, en toevallig is die code het gevolg daarvan.

In 99% van de gevallen hoeft code niet supersnel te zijn en bouw ik veel liever een mooi mechanisme is die eventueel wat langzamer is, maar wel erg duidelijk laat zien (aan iemand die redelijk wat afweet van oo) wat de bedoeling is. Intussen is mijn code meestal niet meer voor een beginnner te begrijpen, maar so be it. Dat is de prijs om van allerlei geavanceerde concepten te gebruiken. Hetzelfde geldt voor snelheid. Snelheid is leuk, maar op een fraaie manier je systeem modeleren is in mijn ogen veel belangrijker.

ps:
als snelheid wel een belangrijke factor wordt, dan zijn er natuurlijk andere regels

[Verwijderd]

Als je wilt weten of een getal n priem is, hoef je het niet door alle getallen < n te delen om daar achter te komen.

Deel alleen door de getallen in je eigen priemgetallen lijst! Die heb je immers tot aan het getal wat je nu test bijgewerkt En deel nooit verder dan door x <= sqrt(n).

just my 2 cents...

[Olaf van der Spek]

.oisyn schreef op 08 augustus 2002 @ 23:23:
echter, als ik in de for lus ergens een continue statement heb staan, gaat ie door naar de volgende iteratie, maar eerst voert ie c nog uit. Bij een while-lus wordt dat gewoon overgeslagen, waardoor je met if-constructies ervoor moet zorgen dat ie toch nog uitgevoerd wordt (duur dus gewoon geen continue te gebruiken). Je kunt natuurlijk ook wel die c zetten voor elke continue, maar persoonlijk vind ik dat nog lelijker

Mee eens. De keuze tussen for en while hangt bij mij meestal af van het aantal expressies dat ik in for nodig zou hebben.