XProfan

Frank
Abbing

[quote:fbfd3c2763]Von wegen eine Zeile, unter Umständen erspart man sich wesentlich mehr, da man erst einmal einen Flag setzen muss, um in der While-Schleife zu bleiben und natürlich muss man den Flag zurücksetzen, um wieder aus der Schleife heraus zu kommen. Der Umweg über
Kompilieren Markieren Separieren

Ende% = 0

While Not(Ende%)

    If ()

        Ende% = 1

    Endif

Wend

könnte man sich weitgehenst ersparen. Man erspart sich das If, und das Setzen der Variablen.[/quote:fbfd3c2763]
Weswegen die meissten so eine Variable benutzen, ist mir eh schleierhaft. Sie ist unnötig:
Kompilieren Markieren Separieren

While 1

    Case ():BREAK

EndWhile

Clemens
Meier

@Frank
Mit dem Case ist es oft nicht allein getan und jeder Break ist ein Zwangsabbruch. Aber darüber könnten wir jetzt einen eigenen Thread eröffnen und diskutieren. Der Grund einer While-Schleife sollte nah bei dem While zu finden sein, da sonst der Quelltext unleserlich wird. Die eleganteste Lösung ist eben die Zuweisung direkt beim While, zumal bei einer Zuweisung gleichzeitig mit True und False festgestellt werden könnte, ob die Zuweisung überhaupt erfolgreich war. War sie nicht erfolgreich, wird die While-Schleife erst gar nicht durchlaufen. Unser Programmierlehrer hätte zu einer Konstruktion wie deiner gesagt: Das ist wie eine Ohrfeige zu verteilen, um erst anschließend nach dem Grund zu suchen.

XProfan 9.1; XP SP2; FF; Editpad

Frank
Abbing

Jetzt wirds doch offtopic...

[quote:207333087e]...jeder Break ist ein Zwangsabbruch... Unser Programmierlehrer hätte zu einer Konstruktion wie deiner gesagt: Das ist wie eine Ohrfeige zu verteilen, um erst anschließend nach dem Grund zu suchen. [/quote:207333087e]
Kein Abbruch, sondern ein Sprung zu einer anderen Programmadresse. Meines Erachtens nach die effektivste Lösung.
Das Verlassen einer Schleife durch eine Variable ist langsam und fehleranfällig, weil ggf. folgende Programmteile nicht mehr ausgeführt werden dürfen, sobald die Scheife beendet werden soll. Es könnten also weitere If-EndIf Abfragen nötig sein, die einen Code ebenfalls unübersichtlich machen.
Ich persönlich schreibe meinen Code in Kleinbuchstaben, wobei jeder Silbenanfang mit einem Grossbuchstaben beginnt. Z.B. EndIf oder EndWhile. BREAK, CONTINUE, RETURN und notfalls GOTO schreibe ich aber komplett in Grossbuchstaben, sodass sie im Code sehr auffallen. Ist eben meine Methode, um den Überblick nicht zu verlieren.

Um gute Programme zu schreiben, benötigt es keiner starren Limitierungen des Quellcodes. Ich halte es für wichtiger, seinen eigenen Stil zu finden und daran herumzufeilen, bis er selber als optimal empfunden wird. Ein durchaus langwieriger bis nie endenwollender Prozess.
Und... Lehrer waren mir schon immer unsympathisch. Dietmar Horn ausgenommen

Senf:

Franks Break ist optimal.

@Roland: Gibt es Situationen in denen ein Break

im XProfan10 nicht aufgerufen werden sollte - bzw. kann bedenkenfrei aus jeder Schleife und if-Konstruktion gebreakt werden? (Wie verhält sich mit Continue

und Return

23.04.2006 ▲

RGH

[quote:7956377d64=iF]@Roland: Gibt es Situationen in denen ein Break

im XProfan10 nicht aufgerufen werden sollte - bzw. kann bedenkenfrei aus jeder Schleife und if-Konstruktion gebreakt werden? (Wie verhält sich mit Continue

und Return

?)[/quote:7956377d64]
Hallo,
bei der Betrachtung müssen wir Return

extra behandeln.

Zunächst zu Break

und Continue

:
Optimal steht ein Break

oder Continue

außerhalb einer IF

-Struktur hinter einem Case

. Aber selbst innerhalb einer IF

-Struktur würde es nur im Extremfall bei sehr unstrukturierter Programmierung zur Fehlermeldung zu tiefe IF/ENDIF-Verschachtelung führen. (Ich bezweifele, daß diese Fehlermeldung je einer zu Gesicht bekommt, es sei denn er provoziert das ganz bewußt. Man müßte ca. 10 Millionen Mal eine IF-Struktur mittendrin mit BREAK

verlassen, ohne die Prozedur, in der das geschieht, jemals zu verlassen. Beim Verlassen einer Prozedur, sei es mit ENDPROC

oder RETURN

, werden alle Stacks auf den Zustand vor Eintritt in die Prozedur zurückgestellt, so dass alles, was in der Prozedur geschah, vergessen und vergeben ist.)

Ein Return

kann eigentlich ohne jede Einschränkung überall in der Prozedur stehen. Die Prozedur wird verlassen und der Stack wieder sauber aufgeräumt. Natürlich sollte man im Auge behalten, daß erzeugte Objekte (Fonts, Bitmaps, Icons) wieder mit DELETEOBJECT

gelöscht ud geDIM

te Bereiche vorher wieder DISPOSE

d werden. Die erzeugten Bereiche belegen sonst bis zum Programmende Speicher und die drei genannten Objekte leider noch darüber hinaus (aber nur recht wenig). Vor allen, wenn man eine Prozedur sehr oft aufruft, kann das rasch zu unerwünschten Nebenwirkungen führen.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

23.04.2006 ▲

So kann man arbeiten...

23.04.2006 ▲

Joerg

Hallo zusammen,

@Roland: Der Beitrag ist zwar schon 10 Jahre alt, aber mich interessiert, ob das mit den aktuellen XProfan Versionen noch genau so ist, dass der Stack aufgeräumt wird, wenn man eine Prozedur vorzeitig mit Return oder Endproc verlässt...

Danke und Grüße!!
Jörg

27.06.2016 ▲

RGH

Ja, da hat sich nichts geändert!
Gruß
Roland

XProfan X3
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

27.06.2016 ▲