Discussie'tje over GOTO functie.

[blijhoofd_bennie]

Ik zat op het werk en zat opeens te denken, op school leer je altijd je mag de GOTO functie (zoals in pascal niet gebruiken). In VB mag het wel, maar is niet netjes.

Maar ik vroeg me dus af...
Als je het niet mag gebruiken om naar iets te springen
if.... then
else
goto end:
Maar wel voor het aangeven van beelscherm coordinaten (in pascal) mocht het wel?

Maar als je die functie niet mag gebruiken om door te verwijzen naar een ander stuk code in je programma, waarom maken ze het dan mogelijk? (waarom niet alleen maar puur cords invullen als het voor beeldscherm gebruik is).

En mijn volgende gedachte was, je mag toch wel naar een Case verwijzen in een if then structuur?

if ... then
case1
else
case2

Dit doe ik wel eens, maar dat mag wel? is dat dan kwa principe niet hetzelfde als goto?

Hier zou ik wel eens julie mening over willen horen.

[drm]

Ik begrijp dat in pascal de goto functie een grafische functie is waarmee je de grafische cursor verplaatst, dus die heeft er op zich niets me te maken? Correct me if i'm wrong...

Het grootste nadeel van de goto-construct (da's dus geen functie) is dat er geen logisch verloop in de code meer bestaat. Je kunt in de code nooit nagaan "waar je vandaan gekomen bent".

[Spooksel]

gotoXY(getal,getal);

Dit zorgt er in pascal idd voor dat je op een aangegeven locatie op het scherm iets kunt afdrukken.

[Tjark]

"GOTO isn't evil, it's just sometimes used by people for evil intentions".

* Tjark vindt GOTO toch wel vies

en ach: http://www.azillionmonkeys.com/qed/goto.html

[Dido]

GOTO is het equivalent van een van de meest elementaire machinetaalinstructies: JMP (Jump) of BR (Branch).

Iedere programmeertaal heeft die mogelijkheid dus wel ergens ingebouwd. Zelfs als je andere constructies gebruikt (ouwe Basic GOSUB bijv.) wordt dat "vertaald naar een machinetaal GOTO.

Het probleem is dat je programma er simpelweg onleesbaar door wordt omdat je niet meer eenvoudig kunt volgen waar je naartoe jumpt, waar je vandaan kwam, en belangrijker, waar je uiteindelijk uitkomt. Vandaar dat in iedere programmeertaal de GOTO "verboden" wordt.

[Verwijderd]

Dido: ben ik het niet mee eens.
Een programmeur zorgt ervoor dat zijn software onleesbaar word niet zijn GOTO commando.

Er is absoluut niets mis met een GOTO. Wat er wel mis is is dat programmeurs vroeger vaak naar de eenvoudige oplossing grepen ipv een minuutje langer nadenken en een manier gebruikten die PSD-waarig is. Een GOTO is in 99% van de gevallen niet nodig en kan het anders opgelost worden.

[bras]

Uit Linux Device Drivers, 2nd Edition van O'Reilly

Error recovery is sometimes best handled with the goto statement. We normally hate to use goto, but in our opinion this is one situation (well, the only situation) where it is useful. In the kernel, goto is often used as shown here to deal with errors.

[Verwijderd]

Op donderdag 11 april 2002 14:49 schreef bras het volgende:
Uit Linux Device Drivers, 2nd Edition van O'Reilly
[..]

Daarvoor gebruik ik het meestal ook, error recovery in functies (zowel in applicaties als in de kernel). Daarvoor is het uitermate goed geschikt, het scheelt een berg aan if (..) {..} constructies.

Voor de rest is er vaak wel een schonere oplossing te bedenken dan goto. Als dat kan, zeker doen. Als dat niet kan, goto gebruiken. De goto feature is er niet voor niks .

[EXX]

Op donderdag 11 april 2002 14:44 schreef Dido het volgende:
GOTO is het equivalent van een van de meest elementaire machinetaalinstructies: JMP (Jump) of BR (Branch).

Iedere programmeertaal heeft die mogelijkheid dus wel ergens ingebouwd. Zelfs als je andere constructies gebruikt (ouwe Basic GOSUB bijv.) wordt dat "vertaald naar een machinetaal GOTO.

Het machinetaalequivalent van GOSUB is geen JMP of BR maar CALL (of SUB). Deze zetten i.t.t. jumps het returnadres op de stack. Bij het uitvoeren van de RET (return) instructie neemt ie dat van de stack en gaat dan door na de CALL.

[Creepy]

GotoXY en Goto zijn 2 heel verschillende dingen. GOtoXY wordt in (Borland) Pascal gebruikt om een ander scherm coordinaat op te geven voor verschillende teken en text functies.

Ikzelf gebruik goto nooit. Waarom?

1: Je moet zelf bijhouden waar je zit en waar je naartoe (terug) moet springen
2: Alles is te schrijven zonder goto (gebruik if/while/for/case etc.)
3: Structuur van (een deel van) het programma is minder overzichtlijk. Helemaal leuk als iemand anders jou code moet gaan aanpassen o.i.d. Je moet namelijk zelf nagaan waarvan gesprongen is etc. (omgekeerde van 1).

On Error Goto (in basic dan) vindt ik niet eens zo vies, want je kan dan toch ook nog iets ala RETURN doen toch (ala de GOSUB)?

[Dido]

ItSnows schreef:
Dido: ben ik het niet mee eens.
Een programmeur zorgt ervoor dat zijn software onleesbaar word niet zijn GOTO commando.
[..]

Klopt. Zo bedoelde ik het ook meer. Ik had het iets beter kunnen verwoorden. Het is echter vaak een grotere "uitdaging" (lees: probleem) voor een programmeur om z'n code leesbaar te houden met GOTO's. Dus worden ze "verboden". En inderdaad, het kan (bijna) altijd anders. (Al is het maar met een call waarna je het returnadres op de stack veranderd )

EXX schreef:Het machinetaalequivalent van GOSUB is geen JMP of BR maar CALL (of SUB). Deze zetten i.t.t. jumps het returnadres op de stack. Bij het uitvoeren van de RET (return) instructie neemt ie dat van de stack en gaat dan door na de CALL.[..]

Mijn fout. Wat je zegt klopt inderdaad. Er zijn (waren?) wel sommige compilers die hier geen gebruik van maken, zodat het uiteindelijk toch jumps worden...

Wat betreft de foutafhandeling met behulp van de goto: het kan ook anders. Ik zit (helaas) nog al eens wat onderhoud te plegen aan (oude) programmatuur waarin dat gebruikt wordt, en het maakt de code er nietoverzichtelijker op. Het is me wel eens opgevallen dat VBA-wizzards de on error gote in iedere module meenemen (en dus overal een zooi identieke code neersmijten...)

[marcelk]

Voor de liefhebber:
A Case against the GO TO Statement of wel "GO TO considered harmful" van E.W. Dijkstra. (PDF)

[Verwijderd]

Op donderdag 11 april 2002 15:09 schreef Creepy het volgende:
On Error Goto (in basic dan) vindt ik niet eens zo vies, want je kan dan toch ook nog iets ala RETURN doen toch (ala de GOSUB)?

Het makkelijke is dat je iets kan doen als:

code:

int fd;

static boolean
open_device(char *device)
{
  fd = open(device, O_RDWR);
  if (fd <= 0)
    goto error;

  if (ioctl(fd, SOME_IOCTL, &some_arg) < 0)
    goto error;

  return TRUE;

error:
  printf("Error occurred: %s\n",
    sys_errlist[errno]);
  if (fd > 0)
    close(fd);
  fd = 0;
  return FALSE;
}

Nou kan je dit ook wel allemaal herschrijven, dus elke goto vervangen door de hap om te kunnne returnen, maar maintainability is veel simpeler zo, vooral als je dus niet 2 maar 20 dingen op die file descriptor uitvoert.

[TlighT]

Er zijn imho twee algemene gevallen waarin het toegestaan is GOTO te gebruiken:

1. Error recovery (wanneer de gebruikte taal geen exceptions ondersteunt)
2. Het springen uit een geneste loop (als de taal geen labelled breaks o.i.d. ondersteunt)

en eigenlijk nog:

3. Speciaal voor c#, om naar een specifiek switch-case label te springen (in het geval van een fall-through o.i.d.)

[Dido]

Op donderdag 11 april 2002 16:56 schreef beelzebubu het volgende:
[..]
Nou kan je dit ook wel allemaal herschrijven, dus elke goto vervangen door de hap om te kunnne returnen, maar maintainability is veel simpeler zo, vooral als je dus niet 2 maar 20 dingen op die file descriptor uitvoert.

En wat is er verkeerd met iets als

code:

procedure PROGJE
  RETCDE = TRUE
  [..]
  if (er is iets fout)
    call FOUT
  endif
  return RETCDE
end proc

sub FOUT
  print je foutmelding
  RETCDE = FALSE
end sub

beetje pseudocode...

[Verwijderd]

Goto is goed voor assembly.. anders.. AFBLIJVUH!

[serkoon]

Op donderdag 11 april 2002 17:00 schreef Dido het volgende:

[..]

En wat is er verkeerd met iets als

code:

procedure PROGJE
  RETCDE = TRUE
  [..]
  if (er is iets fout)
    call FOUT
  endif
  return RETCDE
end proc

sub FOUT
  print je foutmelding
  RETCDE = FALSE
end sub

beetje pseudocode...

Dat gaat niet altijd lekker werken. Bijv:

code:

if (doeiets()<0) { 
    fout(); 
} else { 
    if (doeietsanders()<0) {
      fout();    
    } else {
      if (doenogietsanders()<0) {
        fout();
      } else { 
        printf("jeuh!\n"); 
      } 
    }
}

Vaak is een goto in zulke gevallen een perfecte methode om overzichtelijke en tevens nette code te houden.

[Verwijderd]

Op donderdag 11 april 2002 17:00 schreef Dido het volgende:

[..]

En wat is er verkeerd met iets als
-code-
beetje pseudocode...

Dat kan dus niet in C op een nette manier. En ik vrees dat het ook niet in C++ kan of in java (not sure about these)...

[Dido]

Op donderdag 11 april 2002 19:30 schreef beelzebubu het volgende:

[..]

Dat kan dus niet in C op een nette manier. En ik vrees dat het ook niet in C++ kan of in java (not sure about these)...

Tsja... COBOL heeft voordelen

Maar (niet optimaal, geef ik toe), dit moet kunnen?

code:

  int retcde;
  retcde = doeiets();
  if (retcde = goed)  retcde := doeietsanders();
  if (retcde = goed)  retcde := doenogietsanders();
  if (retcde != goed) fout();
  return retcde;

Dan moet je wel ondescheid kunen maken tussen foutsituaties afhankelijk van retcde... ik geef toe dat dit niet altijd het makkelijkste werkt, maar je kunt in een global structure je foutmeldingen laten zetten door je functies.

[Creepy]

Op donderdag 11 april 2002 16:56 schreef beelzebubu het volgende:

[..]

Het makkelijke is dat je iets kan doen als:

code:

int fd;

static boolean
open_device(char *device)
{
  fd = open(device, O_RDWR);
  if (fd <= 0)
    goto error;

  if (ioctl(fd, SOME_IOCTL, &some_arg) < 0)
    goto error;

  return TRUE;

error:
  printf("Error occurred: %s\n",
    sys_errlist[errno]);
  if (fd > 0)
    close(fd);
  fd = 0;
  return FALSE;
}

Nou kan je dit ook wel allemaal herschrijven, dus elke goto vervangen door de hap om te kunnne returnen, maar maintainability is veel simpeler zo, vooral als je dus niet 2 maar 20 dingen op die file descriptor uitvoert.

code:

int fd;

static boolean
open_device(char *device)
{
  fd = open(device, O_RDWR);
  if (fd > 0)
    if (ioctl(fd, SOME_IOCTL, &some_arg) >= 0)
     return TRUE;

  printf("Error occurred: %s\n",
    sys_errlist[errno]);
  if (fd > 0)
    close(fd);
  fd = 0;
  return FALSE;
}

Was het niet zo dat een return in C meteen er uit springt?

Maar ik heb liever iets ala dit, zodat je voor de gebruiker fatsoenlijke foutmeldingen kan geven (in het NL bijv.):

code:

int fd;

static boolean
open_device(char *device)
{  
  fd = open(device, O_RDWR);
  
  if (fd > 0)
  {
    if (ioctl(fd, SOME_IOCTL, &some_arg) >= 0)    
    {
    return TRUE;
    }
    else
    {
    Printf("Oops.. foutje"..);
    }
  }
  else
  {
    Printf("Heu.. kan dat ding niet openen! Hebbie wel de juiste rechten?");
  }
  return FALSE;
}

[whoami]

Ik dacht het niet.

[Dido]

Op vrijdag 12 april 2002 09:24 schreef whoami het volgende:
Ik dacht het niet.

Wat niet

[Creepy]

Op vrijdag 12 april 2002 09:24 schreef whoami het volgende:
Ik dacht het niet.

Van how stuff works.. mijn C boek heb ik niet op m'n werk
http://www.howstuffworks.com/c6.htm

The return statement is important to any function that returns a result. It specifies the value that the function will return and causes the function to exit immediately. This means that you can place multiple return statements in the function to give it multiple exit points

[jjbstolk]

Ik heb altijd geleerd dat iemand die programmeert en goed nadenket (vooraf) over het te maken stuk code dat hij/zij GOTO niet hoeft te gebruiken.

Een van m'n leraren zij altijd "Een goede programmeur gebruikt geen GOTO".

[Birk]

Op vrijdag 12 april 2002 09:46 schreef jjbstolk het volgende:
Een van m'n leraren zij altijd "Een goede programmeur gebruikt geen GOTO".

En de vraag is nu dus, en waarom zij je leraar dit

[drm]

Error handling is sowieso natuurlijk altijd een uitzondering. Niet voor niets dat een Error doorgaans ook wel "Exception" of "uitzondering" genoemd wordt. (Of "errors" is een subset van "exceptions"...).

Oftewel, het normale verloop van een programma wordt onderbroken door een bepaalde foutieve handeling, of een omgevingsfout of wat dan ook. In dat geval wordt er terplekke besloten (imo) of een een error een "fatale" uitzondering is (waarbij het verloop inderdaad niet door kan gaan), of dat er enkel een deelgebied van het programma niet verder kan gaan ("non-fatale" uitzondering).

In het eerste geval is goto geen probleem (het programma wordt toch afgebroken, dus verdere ontwerp kwesties zijn niet aan de orde).

In het laatste geval, is de uitzondering niet meer dan weer een stukje informatie dat verwerkt moet worden.

Wat dat betreft is het "throw - catch"-principe natuurlijk het mooist. Wanneer het om een fatale uitzondering gaat, wordt de throw aan het OS gegeven, anders aan de caller van de handeling. Degene die een bepaalde handeling doet moet uitzoeken wat er moet gebeuren als die handeling mislukt, en niet de handeling zelf. Da's mijn idee

Hoe implementeer je zoiets in een omgeving die geen throw-catch principe kent? Precies: returns.

Zo is het dus ook in C gedaan, de main () returnt een not zero waarde wanneer er iets fout gaat (een foutcode) net als een groot gedeelte van de andere procedures.

Wat ik hier precies mee wil zeggen weet ik pas als iemand er op reageert

[chaozz]

Op vrijdag 12 april 2002 09:54 schreef Birk het volgende:

[..]

En de vraag is nu dus, en waarom zij je leraar dit

.. waarom zij je leraar.. GOTO school!

[Creepy]

In dat geval reageer ik erop
Maar moet zeggen dat ik het helemaal met je verhaal eens ben.

[Birk]

Op vrijdag 12 april 2002 10:36 schreef chaozz het volgende:
.. waarom zij je leraar.. GOTO school!

ja maar waarom gebruiken we geen GOTO omdat mijn leraar dat zij...

Kom dan met een goede argumentatie... Enne ik ben het wel met iedereen eens hoor

[MrEdge_]

Voor de mensen die GOTO voor foutafhandeling gebruiken: Daar is toch een mooi try/throw/catch mechanisme voor gemaakt?

[The End]

Op vrijdag 12 april 2002 10:24 schreef drm het volgende:
Error handling is sowieso natuurlijk altijd een uitzondering. Niet voor niets dat een Error doorgaans ook wel "Exception" of "uitzondering" genoemd wordt. (Of "errors" is een subset van "exceptions"...).

[knip]

Meestal is een normaal verloop van een programma een uitzondering....

Als je goto moet gebruiken om de code overzichtelijk te houden (en maintainable), dan heb je te grote functies geschreven!

[chaozz]

Op vrijdag 12 april 2002 10:41 schreef Birk het volgende:

[..]

ja maar waarom gebruiken we geen GOTO omdat mijn leraar dat zij...

Kom dan met een goede argumentatie... Enne ik ben het wel met iedereen eens hoor

waar ik op doelde was je spelfout. je bedoelt: wat mijn leraar zei (en niet 'zij')

over GOTO:

op de commodore64 gebruikte ik alleen maar GOTO's, in QBasic ook trouwens. in Turbo Pascal ving ik dit op met Procedures en Functions. en nu in Delphi/VB gebruik ik hooguit een 'dirty' exit sub.

kortom: goed gestructureerde code heeft geen code nodig.

[Birk]

Op vrijdag 12 april 2002 10:58 schreef chaozz het volgende:
waar ik op doelde was je spelfout. je bedoelt: wat mijn leraar zei (en niet 'zij')

Off-Topic:

Aha ok dat maakt het duidelijker

Het is duidelijk, het is vroeg en ik slaap nog...

[Verwijderd]

Ik gebruik in VB GOTO alleen in on error goto ...

GOTO maakt je programma zo 'lekker' onlogisch en ongestructureerd. Bij het aanroepen van een procedure komt het progsel weer terug en weet je dus al lezend wat er gebeurd. Bij een GOTO dus niet. Hetzelfde geldt voor de werkelijke doorloop van je progsel.

Ik ben overigens nog nooit een stuk code tegengekomen wat zonder GOTO niet te doen was.

[drm]

jjbstolk: Een van m'n leraren zij altijd "Een goede programmeur gebruikt geen GOTO".

Birk: En de vraag is nu dus, en waarom zij je leraar dit

[En alle andere reacties daarop]

En ik maar denken dat Birk niet voor niets http://www.dyslexie.nl in z'n sig had staan

Creepy:
In dat geval reageer ik erop

Maar moet zeggen dat ik het helemaal met je verhaal eens ben.

Da's alvast 1. Wie volgt?

[Birk]

Op vrijdag 12 april 2002 11:19 schreef drm het volgende:
En ik maar denken dat Birk niet voor niets http://www.dyslexie.nl in z'n sig had staan

Ja ik denk ik moet daar iets zetten Hey enne het is ook nog echt zo

[Verwijderd]

Je moet eens naar de linux kernel kijken, daar worden zat goto's gebruikt. Het gebruik van break is ook een beetje vies, trouwens. Maar die wordt wel vaker (en voor C switch zelf verplicht) gebruikt.

[drm]

Prophet_van_Kleunen:
Het gebruik van break is ook een beetje vies, trouwens.

Inderdaad, maar wel minder vies, omdat een break altijd naar dezelfde plek springt, namelijk precies na de afsluitende } van de scope.

Maar die wordt wel vaker (en voor C switch zelf verplicht) gebruikt.

Mwjah wat de switch betreft vind ik het niet zo vies, want dat is gewoon een onderdeel van de semantiek. Switch is overigens toch niet veel meer dan een if elseif else constructie.

[Creepy]

Op vrijdag 12 april 2002 11:28 schreef Prophet_van_Kleunen het volgende:
Je moet eens naar de linux kernel kijken, daar worden zat goto's gebruikt. Het gebruik van break is ook een beetje vies, trouwens. Maar die wordt wel vaker (en voor C switch zelf verplicht) gebruikt.

Een goto is over het algemeen sneller (en kleiner) dan code die hetzelfde doet zonder goto maar met behulp van while/if/case etc. En dit soort micro optimalisatie is voor een kernel van belang. Ook is de kernel op "laag niveau" geprogrammerd (delen ervan rechtstreeks in asm etc.) Uiteraard voor de snelheid.

De linux kernel is nou niet altijd een schoolvoorbeeld van netjes programmeren te noemen

[Verwijderd]

Zoveel sneller zal het niet zijn, dat zal de reden niet zijn. Want zoals veel mensen het met me eens zullen zijn: het gaat (meestel) om de complexiteit, en niet om de programmeer taal die de snelheid van de code zullen bepalen. En die paar goto's zijn maar peulen schillen.

Het enige assembly code die in de kernel zitten zijn hardware specifieke gedeeltes, en de geoptimaliseerde routine's voor geheugen copy (3dnow, mmx, etc...)

[Verwijderd]

Het gebruik van excepties is over het algemeen nogal "duur" (in geheugen gebruik). Daarom wordt het vaak niet gebruikt (zoals in KDE).

Het is idd wel mooier. Maar je kan ook error handling hebben zonder goto's

[drm]

Op vrijdag 12 april 2002 11:59 schreef Prophet_van_Kleunen het volgende:
Want zoals veel mensen het met me eens zullen zijn: het gaat (meestel) om de complexiteit, en niet om de programmeer taal compiler die de snelheid van de code zullen bepalen. En die paar goto's zijn maar peulen schillen.

Heeft natuurlijk niets met de taal te maken, maar alles met hoe de compiler er mee omspringt. Daarom is het van belang te weten hoe en wat de compiler optimaliseert, en vervolgens een keuze te maken in snelheid. Als een compiler "slim" genoeg is, maakt het uiteindelijk niet uit welke techniek je waarvoor gebruikt, maar dat zal in de praktijk anders zijn.

[Verwijderd]

nee, zelfs niet met de taal.

Complexiteit is groter, daarbij valt het snelheids verschil in het niet. Linear vs. Exponentieel

[Verwijderd]

Compilers zijn slim met optimaliseren, maar als ze zelfs de complexiteit van problemen omlaag brengen, dan hoeft de programmeur niets meer te doen !

[drm]

Prophet_van_Kleunen:
Compilers zijn slim met optimaliseren, maar als ze zelfs de complexiteit van problemen omlaag brengen, dan hoeft de programmeur niets meer te doen !

Nee, je maakt nu imo de fout te zeggen dat programmeren afhankelijk is van een taal. En dat is dus niet waar.

Programmeren is namelijk het oplossen van verschillende problemen, en in welke taal dat gebeurt is verder irrelevant.

Zo zou je bijvoorbeeld een probleem "ik wil x met 10 ophogen" kunnen hebben.

Als ik dit beschrijf zeg ik:

code:

Hoog x met 10 op

Als ik dit codeer in bijvoorbeeld C, zeg ik:

code:

x += 10;

Als ik vervolgens een verkeerd "algoritme" bedenk, en het als volgt doe:

code:

x += 5;
x += 5;

En de compiler ziet dat dit 2 handelingen zijn (slimme compiler ) waar er 1 gemaakt van kan worden, compileert hij het vervolgens tot 1 handeling waarin x met 10 opgehoogd wordt, ipv 2x met 5

Dan is het verder niet relevant dat dat in C geschreven is, want exact hetzelfde kun je in elke andere taal doen. En dus kan elke compiler optimaliseren, ongeacht voor welke taal hij geschreven is.

Vervolgens heeft de complexiteit van een probleem niets met optimalisatie te maken, maar de implementatie van een algoritme is belangrijk voor optimalisatie. Of die implementatie dan complex is of niet, is niet van belang.

[RickN]

Op vrijdag 12 april 2002 12:43 schreef Prophet_van_Kleunen het volgende:
nee, zelfs niet met de taal.

Complexiteit is groter, daarbij valt het snelheids verschil in het niet. Linear vs. Exponentieel

Klok? Klepel? Waar?

[Verwijderd]

Stel je implementeert een qsort, en een linear sort.

stel (we laten worst-case behaviour dan even weg), je linear sort code wordt geoptimaliseerd met een shuffle, waar een multiply stond in je interne loop.

Maar dan valt die optimalisatie toch in het niet bij de snelheid van qsort ?

netzoals de paar nette while lusjes, niet veel verschil uit zullen maken in de memory manager van een kernel.

[drm]

Wat heeft het nou voor zin om 2 verschillende algoritmen te gaan vergelijken als je het over compiler-niveau optimalisatie hebt

[Pelle]

* Pelle moest van * drm zeggen dat * Pelle vond dat * drm gelijk heeft

Ik gebruik het zelf nog te weinig, maar het afvangen van fatal errors is natuurlijk erg netjes. Ik moet altijd weer hard lachen als ik een site zie waar iemand gebruikt heeft gemaakt van bijvoorbeeld de or die functionaliteit in PHP, en er mooi in times new roman 10pt op een witte achtergrond komt te staan:

Euhm ja, doet niet.

Maak er dan op z'n minst iets van dat error-codes in een nette layout kan vertalen naar iets dat de gebruiker snapt.. dat de mysql server koffie aan het drinken is ofzo

maare, ik dwaal af

[RickN]

Je bent idd appels met peren aan het vergelijken. Complexiteit van een algoritme is zeg maar "design time" terwijl de optimalisaties waar we het hier over hebben "implementation time" zijn. Natuurlijk is een F1 wagen sneller dan een BMW M3, maar dat betekend niet dat het geen zin heeft om een BMW M3 te tunen...

Het globale effect van een locale optimalisatie hangt sterk samen met fractie van de executie tijd waar de geoptimaliseerde code wordt uitgevoerd. Je praat hier over de kernel van een OS, lijkt me best belangrijk om dat een beetje goed te doen.

Bij complexiteit komt dus ook altijd nog een constante om de hoek kijken die in de theoretische complexiteit niet naar voren komt, met implementatie optimalisaties kun je iets aan die constante doen. Dat is zeker wel zinvol. In sommige gevallen (lees praktijk situaties) maakt die constante een algoritme met een hogere complexiteit aantrekkelijker dan een algoritme met een lagere complexiteit.

Om op je sorteer voorbeeld terug te komen. Een slimme implementatie van quicksort maakt gebruik van een insertionsort (oid) om kleine delen van een array te optimaliseren. Je onderschat gewoon het belang van een goede implementatie. Als jij een brakke qsort in elkaar knutselt en maak een insertion sort in asm, dan win jij natuurlijk nog steeds als we een array van 100000000 items gaan sorteren, maar dat is misschien wel helemaal niet relevant in een praktijk situatie. Dan ben ik het nog steeds wel met je eens dat je eigenlijk toch gewoon een qsort moet implementeren, maar dat wil niet zeggen dat je het niet GOED moet doen.

[drm]

* drm is het voor de verandering weer 'ns met RickN eens

[Creepy]

En dat allemaal omdat ik zei dat een goto wel eens sneller zou kunnen zijn dan code die een if/while/case etc. zou gebruiken

Voor een normale app. zal een paar clock cycle extra geen verschil maken, maar voor een kernel maakt dit wel degelijk uit!

Ook altijd leuk om code te gaan optimaliseren.. wat optimaliseer je en waar? (Maar dat is desnoods weer voer voor een nieuwe thread)

[Verwijderd]

Op vrijdag 12 april 2002 08:46 schreef Dido het volgende:
Maar (niet optimaal, geef ik toe), dit moet kunnen?

code:

  int retcde;
  retcde = doeiets();
  if (retcde = goed)  retcde := doeietsanders();
  if (retcde = goed)  retcde := doenogietsanders();
  if (retcde != goed) fout();
  return retcde;

Op vrijdag 12 april 2002 09:22 schreef Creepy het volgende:

code:

int fd;

static boolean
open_device(char *device)
{
  fd = open(device, O_RDWR);
  if (fd > 0)
    if (ioctl(fd, SOME_IOCTL, &some_arg) >= 0)
     return TRUE;

  printf("Error occurred: %s\n",
    sys_errlist[errno]);
  if (fd > 0)
    close(fd);
  fd = 0;
  return FALSE;
}

Was het niet zo dat een return in C meteen er uit springt?

Maar ik heb liever iets ala dit, zodat je voor de gebruiker fatsoenlijke foutmeldingen kan geven (in het NL bijv.):

code:

int fd;

static boolean
open_device(char *device)
{  
  fd = open(device, O_RDWR);
  
  if (fd > 0)
  {
    if (ioctl(fd, SOME_IOCTL, &some_arg) >= 0)    
    {
    return TRUE;
    }
    else
    {
    Printf("Oops.. foutje"..);
    }
  }
  else
  {
    Printf("Heu.. kan dat ding niet openen! Hebbie wel de juiste rechten?");
  }
  return FALSE;
}

Allebei lopen om het probleem heen

Op donderdag 11 april 2002 16:56 schreef beelzebubu het volgende:
Nou kan je dit ook wel allemaal herschrijven, dus elke goto vervangen door de hap om te kunnne returnen, maar maintainability is veel simpeler zo, vooral als je dus niet 2 maar 20 dingen op die file descriptor uitvoert.

Je moet je dus voorstellen dat de code er dan zo uitziet:

code:

int fd;

static boolean
open_device (char *device)
{
  fd = open(device, O_RDWR);
  if (fd > 0)
  {
    if (functie1(fd) == GELUKT)
    {
    if (functie2(fd) == GELUKT)
    {
      // en dit dus 20 keer
    }
    }
  }

  // en hier de error afhandeling
}

Dat is gewoon niet te doen. Het is lelijk, onoverzichtelijk. Voor error afhandeling is goto perfect. return helpt hier slechts deel somdat je dus behalve return ook een foutmelding wil geven.

code:

int fd;

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) <= 0)
    goto error;

  if (functie1(fd) != GELUKT)
    goto error;

  if (functie2(fd) != GELUKT)
    goto error;

  // .. etc

  return TRUE;

error:
  // en hier de error afhandeling
}

Veel makkelijker, mooier, overzichtelijker

goto is vies in vele situaties. Maar in sommige situaties is het bijzonder handig

[drm]

beelzebubu:
Je moet je dus voorstellen dat de code er dan zo uitziet:

code:

// ...
if (functie1(fd) != GELUKT)
  goto error;
// ...

Veel makkelijker, mooier, overzichtelijker

goto is vies in vele situaties. Maar in sommige situaties is het bijzonder handig

en waarom dan niet zo :?:

code:

void errorHandler ( code )
{
   // en hier de error afhandeling
}

if (errorcode = (functie1(fd) != GELUKT))
   errorHandler ( errorcode );

[dusty]

Een goede programmeur gebruikt geen GOTO.
^{(tenzij hij in machine taal aan het programmeren is.)}

Iedereen die er anders overdenkt moet maar eens een boek over systeemontwerp lezen.

[Knutselsmurf]

Op vrijdag 12 april 2002 17:07 schreef drm het volgende:

[..]

en waarom dan niet zo :?:

code:

void errorHandler ( code )
{
   // en hier de error afhandeling
}

if (errorcode = (functie1(fd) != GELUKT))
   errorHandler ( errorcode );

OMdat hij dan vrolijk verder gaat waar hij was gebleven? En dat was natuurlijk niet de bedoeling, want er was een fout opgetreden........

[Creepy]

Op vrijdag 12 april 2002 17:21 schreef dusty het volgende:
Een goede programmeur gebruikt geen GOTO.
^{(tenzij hij in machine taal aan het programmeren is.)}

Iedereen die er anders overdenkt moet maar eens een boek over systeemontwerp lezen.

Dusty.. mijn held!

[Creepy]

Op vrijdag 12 april 2002 17:02 schreef beelzebubu het volgende:

[..]


[..]

Allebei lopen om het probleem heen
[..]

Je moet je dus voorstellen dat de code er dan zo uitziet:

code:

int fd;

static boolean
open_device (char *device)
{
  fd = open(device, O_RDWR);
  if (fd > 0)
  {
    if (functie1(fd) == GELUKT)
    {
    if (functie2(fd) == GELUKT)
    {
      // en dit dus 20 keer
    }
    }
  }

  // en hier de error afhandeling
}

Dat is gewoon niet te doen. Het is lelijk, onoverzichtelijk. Voor error afhandeling is goto perfect. return helpt hier slechts deel somdat je dus behalve return ook een foutmelding wil geven.

code:

int fd;

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) <= 0)
    goto error;

  if (functie1(fd) != GELUKT)
    goto error;

  if (functie2(fd) != GELUKT)
    goto error;

  // .. etc

  return TRUE;

error:
  // en hier de error afhandeling
}

Veel makkelijker, mooier, overzichtelijker

goto is vies in vele situaties. Maar in sommige situaties is het bijzonder handig

Die eerst loopt om het probleem heen?

code:

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) > 0)
    if (functie1(fd) = GELUKT)
    if (functie2(fd) = GELUKT)
  // .. etc

       return TRUE;
  // error ding hiero...   of zelfs in de caller.
  return false;
}

Hoe bedoel je dat precies?

[Verwijderd]

Op vrijdag 12 april 2002 17:07 schreef drm het volgende:
en waarom dan niet zo :?:

code:

void errorHandler ( code )
{
   // en hier de error afhandeling
}

if (errorcode = (functie1(fd) != GELUKT))
   errorHandler ( errorcode );

omdat de error handler er ook voor moet zorgen dat de functie returnt. en dan kan je wel die return eronder zetten, maar dan kom je dus weer direct op het pad 'je kan er wel omheen lopen, maar goto is gewoonweg veel simpeler in dit soort gevallen'

Op vrijdag 12 april 2002 17:21 schreef dusty het volgende:
Een goede programmeur gebruikt geen GOTO.
^{(tenzij hij in machine taal aan het programmeren is.)}

Iedereen die er anders overdenkt moet maar eens een boek over systeemontwerp lezen.

dankje, ik ben systeemprogrammeur . Ik weet dat goto in sommige gevallen handig is. Iedere zealot die dat zonder enig argument dom denkt te kunnen vinden moet mijn bovenstaande stellingen maar eens lezen. Goto is in sommige situaties handig. Proof me wrong

Op vrijdag 12 april 2002 18:00 schreef Creepy het volgende:
Die eerst loopt om het probleem heen?

code:

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) > 0)
    if (functie1(fd) = GELUKT)
    if (functie2(fd) = GELUKT)
  // .. etc

       return TRUE;
  // error ding hiero...   of zelfs in de caller.
  return false;
}

Hoe bedoel je dat precies?

Je moet je dus voorstellen dat er dus een heleboel functies zijn. Sommige returnen iets, anderen niet, sommige returnen dingen die je anders moet interpretten dan anders, etc.

Voorbeeldje:

code:

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) <= 0)
    goto error;

  if (functie1(fd) != GELUKT)
    goto error;

  functie2(fd);

  int returnwaarde;
  functie3(fd, &returnwaarde);
  if (returnwaarde < 0)
    goto error;

  //.. etc
[..]
  return TRUE;

error:
  return false;
}

(overigens kun je halverwege een functie geen int declareren maar dat vergeten we uit gemaktzucht maar eventjes)

Vergeet niet dat je in een opensource- of bedrijfsomgeving vaak niet in je eentje programmeert. Niet iedereen code exact hetzelfde en dus zijn niet alle APIs identiek qua opbouw. Vooral in C is dat een groot probleem en moet je daar dus op een effectieve manier mee kunnen omgaan.

Op "jouw" manier komt dat er dus ongeveer zo uit te zien:

code:

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) > 0)
  {
    if (functie1(fd) == GELUKT)
    {
    functie2(fd);

    int returnwaarde;
    functie3(fd, &returnwaarde);
    if (returnwaarde < 0)
    {
      //..etc
[..]
                                  return TRUE;
    }
    }
  }

  return false;
}

Je komt steeds verder in de nested situatie terecht, en dat vind ik persoonlijk niet echt 'clean'. En overzichtelijk is het al helemaal niet (denk hierbij aan grotere functies, niet aan de mini-voorbeeldjes die ik hier geef).

[mierenneuken]
ohja, en vergelijkingen in een if is met twee '='jes ipv 1
[/mierenneuken]

Een andere manier die ik soms gebruik om hieruit te komen is een simpele error handler macro definieren, wat overigens al helemaal niet clean is, maar ook vrij simpel werkt en daarnaast ook nog eens per-error-handling mogelijkheden geeft:

code:

#define handle_error(format, args...) \
  { \
    printf(format, ## args); \
    goto error; \
  }

int fd = 0;

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) <= 0)
    handle_error("Error opening device: %s\n",
    sys_errlist[errno]);

  //.. etc.

  return TRUE;

error:
  //.. allemaal resets/etc.
  if (fd > 0)
    close(fd);
  fd = 0;
  return FALSE;
}

In principe kan je op deze manier zelfs van de goto afkomen, alhoewel je code (de bytecode ) er dus wel groter van zal worden dan.

[Creepy]

Op vrijdag 12 april 2002 18:33 schreef beelzebubu het volgende:

[..]

Je moet je dus voorstellen dat er dus een heleboel functies zijn. Sommige returnen iets, anderen niet, sommige returnen dingen die je anders moet interpretten dan anders, etc.

Voorbeeldje:

code:

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) <= 0)
    goto error;

  if (functie1(fd) != GELUKT)
    goto error;

  functie2(fd);

  int returnwaarde;
  functie3(fd, &returnwaarde);
  if (returnwaarde < 0)
    goto error;

  //.. etc
[..]
  return TRUE;

error:
  return false;
}

(overigens kun je halverwege een functie geen int declareren maar dat vergeten we uit gemaktzucht maar eventjes)

Vergeet niet dat je in een opensource- of bedrijfsomgeving vaak niet in je eentje programmeert. Niet iedereen code exact hetzelfde en dus zijn niet alle APIs identiek qua opbouw.

In bedrijfsomgevingen is het de bedoeling dat er OF code guidelines zijn, of een goed ontwerp is geschreven waarin je die zooi gelijkt trekt. Ok.. het gebeurt vaker niet dan wel

Vooral in C is dat een groot probleem en moet je daar dus op een effectieve manier mee kunnen omgaan.

Op "jouw" manier komt dat er dus ongeveer zo uit te zien:

code:

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) > 0)
  {
    if (functie1(fd) == GELUKT)
    {
    functie2(fd);

    int returnwaarde;
    functie3(fd, &returnwaarde);
    if (returnwaarde < 0)
    {
      //..etc
[..]
                                  return TRUE;
    }
    }
  }

  return false;
}

Je komt steeds verder in de nested situatie terecht, en dat vind ik persoonlijk niet echt 'clean'. En overzichtelijk is het al helemaal niet (denk hierbij aan grotere functies, niet aan de mini-voorbeeldjes die ik hier geef).

In dat geval is een goto qua code wel overzichtelijker ja. Maar als het ff kan splits ik die grotere functie op in een paar kleinere. Naar mijn idee is een functie die afhankelijk is van het lukken van een functie die afhankelijk is van het lukken van een functie (maal 30!) een hint om toch eens te kijken of het anders kan.

[mierenneuken]
ohja, en vergelijkingen in een if is met twee '='jes ipv 1
[/mierenneuken]

* Creepy progt de laatste tijd teveel in Delphi

[Verwijderd]

Op vrijdag 12 april 2002 18:59 schreef Creepy het volgende:
In bedrijfsomgevingen is het de bedoeling dat er OF code guidelines zijn, of een goed ontwerp is geschreven waarin je die zooi gelijkt trekt. Ok.. het gebeurt vaker niet dan wel

Vreemd genoeg hebben opensource programmeurs daar ook vaak last van

[Creepy]

Op vrijdag 12 april 2002 19:02 schreef beelzebubu het volgende:

[..]

Vreemd genoeg hebben opensource programmeurs daar ook vaak last van

[Orphix]

GOTO is er idd nog voor de unix bitneukers die geen moderne talen willen gebruiken

Sinds de komst van exceptions in de taal (C++) en een oo manier van programmeren (waarbij een variabele wanneer het uit scoop gaat zelf z'n troep opruimt) is het echt niet meer nodig. Zo zijn ook nummer-regels voor elke regel niet meer nodig.

De voorbeelden die beelzebu geeft vindt ik een beetje dubieus. Als jij in 1 functie 20 operaties doet en bij elke moet checken lijkt het me dat
- je ontwerp fout is en je het zal moeten opsplitsen
- een enkele fout-handling me irreeël lijkt, aangezien je in de functie steeds iets 'verder' komt tot het doel wat je wil bereiken.

En die brackets vind ik ook raar, je verlaat toch de functie wanneer iets fout gaat? En niet bij elke actie die goed is gegaan een nieuwe scope ingaan

[dusty]

Op vrijdag 12 april 2002 18:33 schreef beelzebubu het volgende:
[..]
dankje, ik ben systeemprogrammeur . Ik weet dat goto in sommige gevallen handig is. Iedere zealot die dat zonder enig argument dom denkt te kunnen vinden moet mijn bovenstaande stellingen maar eens lezen. Goto is in sommige situaties handig. Proof me wrong
[..]

Omdat dat als je GOTO gebruikt je niet meer wiskundig kan bewijzen dat je code correct is.

[Verwijderd]

Op vrijdag 12 april 2002 21:10 schreef dusty het volgende:

[..]

Omdat dat als je GOTO gebruikt je niet meer wiskundig kan bewijzen dat je code correct is.

Waarom niet Geef eens een voorbeeld (c.q. bewijs)...

[Verwijderd]

Ik vind goto liev

voorbeeld

blaat.bat

code:

if "%1"=="blaat" GOTO blaat
if "%1"=="file" GOTO file

:blaat
goto end

:file
goto end

:end

[markvt]

Op donderdag 11 april 2002 14:49 schreef ItSnows het volgende:
Dido: ben ik het niet mee eens.
Een programmeur zorgt ervoor dat zijn software onleesbaar word niet zijn GOTO commando.

Er is absoluut niets mis met een GOTO. Wat er wel mis is is dat programmeurs vroeger vaak naar de eenvoudige oplossing grepen ipv een minuutje langer nadenken en een manier gebruikten die PSD-waarig is. Een GOTO is in 99% van de gevallen niet nodig en kan het anders opgelost worden.

GOTO is toch wel nodig soms hoor, als ik in VB iets maak dan wil ik on error goto errorhandler
waar ik dan een formulier laat zien met de error info, is toch verrekte handig dat goto

[Verwijderd]

Op vrijdag 12 april 2002 21:59 schreef markvt het volgende:

[..]

GOTO is toch wel nodig soms hoor, als ik in VB iets maak dan wil ik on error goto errorhandler
waar ik dan een formulier laat zien met de error info, is toch verrekte handig dat goto

idd. maar dat is het m juist. het is juist wel erg makkelijk om even snel naar de GOTO-functie te grijpen, juist terwijl er genoeg andere manieren zijn (ook in vb) om in jouw geval bijvoorbeeld een error afhandelings routine te creeren... manieren die de code 'overzichtelijker' houden. ik ben het wel gedeeltelijk met dido (zie pagina 1) eens over het feit dat de GOTO functie een programma onoverzichtelijk maakt.

[RickN]

Op vrijdag 12 april 2002 21:10 schreef dusty het volgende:

[..]

Omdat dat als je GOTO gebruikt je niet meer wiskundig kan bewijzen dat je code correct is.

LOL, en waar heb je die wijsheid dan wel vandaan??? Heb je ervaring met het bewijzen van code dan??? Nou, ik wel en ik kan je zeggen dat wat je hier zegt grote onzin is.

[Orphix]

Op vrijdag 12 april 2002 21:59 schreef markvt het volgende:

[..]

GOTO is toch wel nodig soms hoor, als ik in VB iets maak dan wil ik on error goto errorhandler
waar ik dan een formulier laat zien met de error info, is toch verrekte handig dat goto

Toch vind ik dit niet helemaal meetellen. Je bepaalt er namelijk niet direct de flow van je programma mee. Het is een soort simpele try-catch die je in veel talen met exceptions tegenkomt.

[Verwijderd]

Op vrijdag 12 april 2002 18:33 schreef beelzebubu het volgende:

[..]

In principe kan je op deze manier zelfs van de goto afkomen, alhoewel je code (de bytecode ) er dus wel groter van zal worden dan.

Je bent niet van je goto af, maar hebt em in een lelijke #define gegooid.

[Pooh]

Op vrijdag 12 april 2002 17:02 schreef beelzebubu het volgende:

Je moet je dus voorstellen dat de code er dan zo uitziet:

code:

int fd;

static boolean
open_device (char *device)
{
  fd = open(device, O_RDWR);
  if (fd > 0)
  {
    if (functie1(fd) == GELUKT)
    {
    if (functie2(fd) == GELUKT)
    {
      // en dit dus 20 keer
    }
    }
  }

  // en hier de error afhandeling
}

Dat is gewoon niet te doen. Het is lelijk, onoverzichtelijk. Voor error afhandeling is goto perfect. return helpt hier slechts deel somdat je dus behalve return ook een foutmelding wil geven.

code:

int fd;

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) <= 0)
    goto error;

  if (functie1(fd) != GELUKT)
    goto error;

  if (functie2(fd) != GELUKT)
    goto error;

  // .. etc

  return TRUE;

error:
  // en hier de error afhandeling
}

Veel makkelijker, mooier, overzichtelijker

goto is vies in vele situaties. Maar in sommige situaties is het bijzonder handig

Dat kan toch net zo makkelijk, en net zo netjes zonder goto met een errorhandling functie?

code:

int fd;

static boolean open_device (char *device)
{
bool no_errors = false;

  fd = open(device, O_RDWR);
  if (fd > 0) no_errors = true;
  else errorhandler(0);
  if (no_errors) no_errors = (functie1(fd) == gelukt)
  else errorhandler(1);
  if (no_errors) no_errors = (functie2(fd) == gelukt)
  else errorhandler(2);
  if (no_errors) no_errors = (functie3(fd) == gelukt)
  else errorhandler(3);
  if (no_errors) no_errors = (functie4(fd) == gelukt)
  else errorhandler(4);

}

[drm]

Knutselsmurf:
OMdat hij dan vrolijk verder gaat waar hij was gebleven? En dat was natuurlijk niet de bedoeling, want er was een fout opgetreden........

Dat KAN, ja, als het geen fatale uitzondering is. Als het wel een fatale uitzondering is, geven we het stokje gewoon weer terug aan het os, en poepen een berichtje "fatale uitzondering" op de console. Waarom kan dat beter in een stukje "goto" code dan in een functie / procedure / subroutine hoe je het ook maar wilt noemen

[Verwijderd]

Op zaterdag 13 april 2002 04:06 schreef Sneechy het volgende:

[..]

Je bent niet van je goto af, maar hebt em in een lelijke #define gegooid.

Wat ik dus bedoelde is at je de code die je uitvoert in het stukje waar de goto naar verwijst, dat je die ook in de lelijke #define kan gooien. Dus zoiets:

code:

#define handle_error(format, args...) \
  { \
    printf(format, ## args); \
    [..andere error afhandeling..]
    if (fd > 0) \
    close(fd); \
    fd = 0; \
    return FALSE; \
  }

int fd = 0;

static boolean
open_device (char *device)
{
  if ((fd = open(device, O_RDWR)) <= 0)
    handle_error("Error opening device: %s\n",
    sys_errlist[errno]);

  //.. etc.

  return TRUE;
}

Sorry dat dat niet helemaal duidelijk was.

[Verwijderd]

Op zaterdag 13 april 2002 09:09 schreef Poohbear het volgende:

[..]

Dat kan toch net zo makkelijk, en net zo netjes zonder goto met een errorhandling functie?

code:

int fd;

static boolean open_device (char *device)
{
bool no_errors = false;

  fd = open(device, O_RDWR);
  if (fd > 0) no_errors = true;
  else errorhandler(0);
  if (no_errors) no_errors = (functie1(fd) == gelukt)
  else errorhandler(1);
  if (no_errors) no_errors = (functie2(fd) == gelukt)
  else errorhandler(2);
  if (no_errors) no_errors = (functie3(fd) == gelukt)
  else errorhandler(3);
  if (no_errors) no_errors = (functie4(fd) == gelukt)
  else errorhandler(4);

}

Het probleem is dat je dus ook nog moet returnen omdat je anderes alsnog door alle errorhandlers gaat... En je code wordt er zeker niet mooi van, het wordt zo een spaghetti van if/else'jes, en dat vind ik nou ook niet bepaald mooi

[Pooh]

Op zaterdag 13 april 2002 10:47 schreef beelzebubu het volgende:

[..]

Het probleem is dat je dus ook nog moet returnen omdat je anderes alsnog door alle errorhandlers gaat... En je code wordt er zeker niet mooi van, het wordt zo een spaghetti van if/else'jes, en dat vind ik nou ook niet bepaald mooi

Die returns zijn het probleem niet natuurlijk, en als ik moet kiezen tussen een serie if/else'jes of een serie goto's, dan weet ik het wel

[Verwijderd]

Op zaterdag 13 april 2002 11:19 schreef Poohbear het volgende:

[..]

Die returns zijn het probleem niet natuurlijk, en als ik moet kiezen tussen een serie if/else'jes of een serie goto's, dan weet ik het wel

/me heeft wel zin in een lekkere moddergooi/welles-nietes discussie

Laat me raden, je gaat voor goto

B.t.w., ik zit nog steeds op het bewijs voor 'een goto is niet wiskundig te bewijzen' ofzo te wachten

[Pooh]

Op zaterdag 13 april 2002 12:37 schreef beelzebubu het volgende:

[..]

/me heeft wel zin in een lekkere moddergooi/welles-nietes discussie

Laat me raden, je gaat voor goto

B.t.w., ik zit nog steeds op het bewijs voor 'een goto is niet wiskundig te bewijzen' ofzo te wachten

* Pooh heeft geen zin in modderbaden...

Dat wiskundig onbewijsbaar lijkt me onzin. Een goto is gewoon een unconditional jump, net als een if-then-else of een case en conditional jump is. Als je een conditional jump kunt modeleren kun je het met een unconditional zeker.

[Verwijderd]

Op zaterdag 13 april 2002 12:37 schreef beelzebubu het volgende:

B.t.w., ik zit nog steeds op het bewijs voor 'een goto is niet wiskundig te bewijzen' ofzo te wachten

quote van pagina

You may have been told that using the goto command in programming is a Bad Idea -- I prefer simply never to tell students that the command exists! The reason behind this is that goto commands break up the loop structure of your program, making it very hard to analyse it and make decisions about its correctness or termination

[Verwijderd]

hard != impossible