INFO - FAQ - CC2-Forum - CCPro-Forum |
> Gut gemeint aber damit geht nicht fogendes: > > IF > in dem fall müßte ich aus dem Unterprogramm "machdies" springen nach "hierhin", und das tut man doch nciht :-) . Es ist ja nicht so, daß ich mein Problem mit "goto's" nicht gelöst kriegte, aber der Quelltext liest sich einfacher wenn es ginge wie wie oben beschrieben... eine weitere Möglichkeit wäre eine zweite if-Bedingung > IF if die Lesbarkeit des Programms ist ja auch davon abhängig wie aussagekräftig die Labelnamen sind gosub Label1 gosub Label2 sagt natürlich jar nischt in Deiner Wunschkonstruktion werden die beiden Befehle hinter THEN bzw. ELSE IMMER ZUSAMMEN ausgeführt und das kannst Du doch im Namen des Labels ausdrücken if mit so allgemeinplätzen sieht das natürlich komisch aus if sagt eine ganze Menge if oder als Variante if Wenn Du Dir für die Benennung da eine bestimmte Konvention festlegst wird es wieder lesbar Die Labelnamen erscheinen Dir möglichweise sehr lang aber: Man macht sich EINMAL etwas länger Gedanken wie man das Unterprogramm nennt und dann kann man den Namen über Strg-C Strg-V an anderer Stelle "schnell schreiben" auch wenn man die Namen immer wieder neu tippt ist das viel weniger nervig als in einemAbkürzungskaudelwelsch immer wieder neu anzusetzen "was macht er denn da ??...??....?? Unterprogramme sollte man IMMER mit Gosub aufrufen nu kann die cc1 nur 4 Verschachtelungsebenen das sollte in den meisten Fällen aber ausreichen goto macht meiner Meinung nach nur in folgenden Fällen Sinn: man prüft an GANZ VIELEN Stellen auf eine bestimmte Bedingung Beispielsweise eine Störmeldung ausgeben oder ähnliches ohne goto müsste man ganz oft eine Verschachtelung programmieren: if KeinAlarm then gosub machwas1 else Alarmauslösen if KeinAlarm then gosub machwas2 else Alarmauslösen if KeinAlarm then gosub machwas3 else Alarmauslösen usw. mit dem goto sieht das dann so aus machwas1 if Alarm goto AlarmAusloesen machwas2 if Alarm goto AlarmAusloesen machwas3 if Alarm goto AlarmAusloesen Da die cc1 eh nicht groß verschachteln kann wird der Vorteil nicht so recht deutlich in Delphi könnte eine Anwendung so aussehen verschiedene Unterprogramme liefern als Ergebniswert null wenn alles OK ist sonst einen Fehlercode abbruch := Machwas1 if abbruch <> 0 then goto Fehlerauswerten abbruch := Machwas2 if abbruch <> 0 then goto Fehlerauswerten abbruch := Machwas3 if abbruch <> 0 then goto Fehlerauswerten 4 5 6 7 8 ...n #Fehlerauswerten sl ich habe das B > > > > Hallo Carsten, > > > > versuche es enmal mit gosub Routine1 und gosub routine2 statt mit action1 und action2. > > > > Also z. B. If i = 1 gosub Routine1 > > If I = 2 gosub Routine2 > > > > oder If i = 1 gosub Routine1 else gosub routine2 > > > > In solchen Unterprogramme kannst Du dann beliebig viele Befehle ausführen lassen. > > > > mfg > > > > Dietmar_B > > > > > Hallo DIE HARD, > > > > > > In der Dokumentation zum IF ("IF condition THEN action1 ELSE action2") fehlt meiner Meinung nach der Hinweis, daß action1 und 2 nur genau eine Anweisung beinhalten dürfen. Es wäre schöner wenn es mehrere wären (das ist der Wunsch), und es kann darüber hianus zu Mißverständnissen führen: > > > > > > define i byte > > > i=1 > > > > > > if i = 1 then i=1:i=2:i=3 'kein syntax - error! > > > print i > > > > > > if i = 1 then i=1:i=2:i=3 ELSE i=4:i=5:i=6 'generiert syntax error > > > print i > > > > > > In diesem Beispiel erhält man eine Syntaxmeldung beim zweiten IF (mit ELSE), aber nicht beim ersten IF. Daher könnte man vermuten, daß i=1:i=2:i=3 nur ausgeführt wird wenn i=1, und nicht (wie es tatsächlich ist), daß i=2 und i=3 in jedem Fall ausgeführt werden. Da sollte der Compiler zumindest auch beim ersten IF sagen "Zeilenende erwartet". > > > > > > Gruß Carsten > > > |
Antwort schreiben |