PureBoard

Weil Goto und Gosub so viele Nachteile haben, hat man die Funktionen und Proceduren entwickelt.
Die Prozeduren sind also eine Weiterentwicklung.
Wer sich Programmiertechnisch weiter entwickeln will, nutzt Prozeduren.
[Edit]
Und bereitet sich dadurch, für OOP vor.
[/Edit]

Darf man nicht ganz so verbissen sehen, weil der PBCompiler macht ja doch wieder "Goto = JMP" draus

Was der compiler macht ist egal.

Letztlich geht's ja nicht drum maschinennah zu coden oder so
wie der Compiler das macht sondern darum, einigermaßen
verständlichen Source zu schreiben, d.h. für den Menschen (oder
wenn schon nicht für Menschen so doch wenigsten für Program-
mierer) lesbar und verstehbar zu gestalten.

Ich nutze selber auch Gotos wenn's mich überkommt, nach dem
Motto : geht und gut. Gerade vorgestern habe ich erst eins be-
nutzt.

Allerdings möchte ich den Code in eigentlich in drei Jahren
nicht nochmal überarbeiten müssen. Da haut so ein Goto
dann ganz schön Kerben in die Hirnhaut.

Oder anders gesagt : Gotos sind persönliche Jobsicherungs-
systeme

"Letztlich geht's ja nicht drum maschinennah zu coden oder so
wie der Compiler das macht sondern darum, einigermaßen
verständlichen Source zu schreiben"

das ist mir nicht egal. ich möchte knappen und schnellen asm-code.
den erzeuge ich nur mit goto und gosub und nicht mit procedure und funktion. die dauern fast das dreifache an zeit, und diese vergeudung ist schon unangenehm.

castle

Makros gibts auch noch. Die sind eigentlich das schnellste.
Werden die häufig benutzt? (Jetzt nicht bei PB - da müsste man IncludeFile nehmen.)

seit 4.0 gibt es Macros in PB.

Macros ist allerdings nur ne "Abkürzung".
zur kompilezeit wird der komplette Inhalt eingefügt.

wenn du irgendwas komplexes statt in eine Proc in ein Macro schreibst,
wird dein Prog vielleicht schneller, aber auch schnell mal 10x so groß.

Sehr sehr schön erklärt.
Ich muss nur leider ein Gegenargument bringen
Aber wenn du zu Anfangszeiten mit einem C64 rum gewurschtelt hast dann Jahre nichts mehr auf dem Gebiet getan hast
dann bekommst du mit dem ganzen Prozeduren schlechter zurecht wie mit goto und gosub.
Tja mit mitte 30 will sich das Gehirn leider nicht mehr umstellen.

seidenraupe hat geschrieben:Sehr sehr schön erklärt.
Ich muss nur leider ein Gegenargument bringen
Aber wenn du zu Anfangszeiten mit einem C64 rum gewurschtelt hast dann Jahre nichts mehr auf dem Gebiet getan hast
dann bekommst du mit dem ganzen Prozeduren schlechter zurecht wie mit goto und gosub.
Tja mit mitte 30 will sich das Gehirn leider nicht mehr um
stellen.

Verstehe nicht wo das Problem liegt.
Goto=Jmp, fällt einfach weg.
Gosub und Return = Parameter puschen und Call und Ret = Prozedur

Da gibts nix zu optimieren. Esseiden der PB-Compiler baut wirklich groben Unfug zusammen, was ich aber nicht glaube.

Ein Prozeduraufruf sollte, wenn man keine Variablen übergibt exakt gleich schnell wie ein Gosub sein, da eigentlich der gleiche Assembler-Code erzeugt werden müsste.

seidenraupe hat geschrieben:Sehr sehr schön erklärt.
Ich muss nur leider ein Gegenargument bringen
Aber wenn du zu Anfangszeiten mit einem C64 rum gewurschtelt hast dann Jahre nichts mehr auf dem Gebiet getan hast
dann bekommst du mit dem ganzen Prozeduren schlechter zurecht wie mit goto und gosub.
Tja mit mitte 30 will sich das Gehirn leider nicht mehr umstellen.

Hallo,
bei mir sind es ~30 Jahre Pc Abstinenze,und ich bin 50+
Was ich nicht so ganz verstehe ist,warum es überhaupt nötig ist,
Name-Spaces zu haben? bzw eine Prozedur daran zu hindern,
Variabeln zu ändern??
Dafür schreibe ich doch die Sub/Prozedur,oder nicht?
Ich brauche bei Sub n Variabele(Global)
Ich brauche bei Proc n*2 Variabele (n für Main;n für proc) plus Eine,
in der das Ergebniss übergeben wird.
Mit einer Variabelen-Liste hatte ich nur selten probleme
Goto ...,wenn dis Programm entweder/oder weiter geht,
ist goto doch das einfachste

Dies ist meine persönliche Meinung,die nicht geteilt werden muss

Olaf

@Olafmagne

Du hast aber noch nie einen größeren Code geschrieben, als vielleicht ein paar 100 Zeilen
"Richtige" Programme sind aber meist wesentlich größer, 10.000 oder mehrere 100.000 Zeilen sind da keine Seltenheit. Wenn da wild umhergejumpt wird, also von einer Procedure in eine andere oder in den Mainscope, dann gibt es natürlich Stackoverflow. Genauso auch z.B. globale Variablen. Wer will den da noch Wissen, welchen Inhalt diese haben sollte oder ob diese nicht bereits mehrmals verwendet wurde oder ob sich nicht was ganz anderes auch ändert, wenn ich die Variable ändere.

Es ist also schon sinnvoll, das Programm in viele kleine, gekapselte Prozeduren zu packen. Der Code ist besser wartbar, testbar und auch verständlicher.

Deine Ansicht mag ja für Dich in Ordnung zu sein, solange Du alleine Programmierst (nicht in Teams) und nicht allzu lange Programme schreibst. Ich persönlich mag solche Codes nicht und ignoriere sie auch meist.

Gruß
Thomas