Hello, Guest the thread was called7.1k times and contains 138 replays

last post from controlport2 at the

Unterprogramm-Aufruf Mit Funktionen

  • Hallöchen,


    Ich fand den 80-Zeichen-Zeilen-Editor in 8 Blocks schon ganz gut.
    Du mußt auch bedenken, daß man im 80-Zeichen-Modus auch doppelt so viele Zeichen pro Scihirm eingeben muß.
    Wenn man pro Zeichen 1 Sekunde rechnet kommt man auf etwa 2000 Sekunden, was in etwa eine halbe Stunde ist. Man sollte dabei auch bedenken, daß man nicht nur schreibt, sondern auch Pausen macht.
    Beim 40-Zeichen Modus würde man auf Tausend Sekunden, also 16 min kommen.
    Und beim Doppelzeichen-Modus auf 500 Sekunden, also etwa 8 Minuten.


    Schönen Gruß, Dirk

  • Hallöchen,


    Hier kommt nun das Listing.
    Zu bedenken ist, das FN nicht wie gosub oder goto mit Zeilensuche arbeitet, sondern mit Variable direkt zur Funktion springt.
    Das a$ löst nun einen Fehler aus. Ab jetzt wird über den Startvektor zur Interpreterschleife gesprungen, also der Code nach dem a$ ausgeführt.
    if a$ goto wertet die Zahlen aus, die in der Funktionsvariablen angeben sind und ignoriert gleichzeitig den return-Befehl in den deffn-Zeilen(10,20).
    Es wird dann in den nächsten Zeilen das Unterprogramm abgearbeitet.
    Und schließlich mit dem sys59736 zurück zum FN-Befehl gesprungen.
    Das Beispiel zeigt einen 2 maligen Funktionsaufruf in einer Rechenoperation (Zeile 3).



    Natürlich kann man nach dem a$ auch noch andere Bedingungen eingeben:
    if0then:return: ---ignoriert das return immer
    if1goto11: ---springt immer zu Zeile11
    usw. Man kann im Prinzip jeden Befehlscode eingeben, der keinen Doppelpunkt beinhaltet. Nur rem funktioniert nicht.


    Schönen Gruß, Dirk

  • Auf Anregung von Hogo habe ich mir überlegt, ob man das PRG nicht mit der USR-Funktion machen könnte. Und es geht auch.
    Hier das Listing mit der USR-Funktion. Man muß nur den USR-Vektor statt den Startvektor nehmen und statt dem a$; ein usr(a$) in der Funktion nehmen.



    Schönen Gruß, Dirk

  • Hier noch mal ein Update zu dem Funktions-Aufrufs-Trick.


    Damit wäre wieder einmal eine Basic-Gehtnicht-Legende ins Reich der Fabeln geschickt.
    Auch Unterprogramme mit Funktionen sind möglich.


    Schönen Gruß, Dirk


    Code
    1. 1 :gosub10:rem---fn-sub
    2. 2 :poke785,228:poke786,167:
    3. 3 :a=fna(.):sys58451:poke19,.:
    4. 4 :print"ok":end
    5. 9 :
    6. 10 :def fna(a)=usr(.);ifagoto18:return
    7. 11 :print"fktn1:":
    8. 18 :sys59736:return
  • Einerseits sehr pfiffig, die FN-Funktion als gosub mit Label zu missbrauchen, andererseits muß man weiterhin die Zeilennummern kennen, um zur Definition springen zu können. Das ist ein bisschen am eigentlichen Sinn von Labeln vorbeigeschossen.


    Die Logik des Programms ist allerdings nur mit einem ROM-Listing in Assembler zu verstehen, wenn überhaupt. Eine selbst programmierte Basic-Erweiterung wäre in mancher Hinsicht besser: Lesbarerer Basic-Text, ohne Assembler verständlich, Label auch ohne Wissen um Zeilennummern möglich.


    Wenn Außenstehende das Hobby C64 seltsam und unnütz finden, diese Form des Basic-Hobbys finde ich selbst als Eingeweihter "seltsam" und unnütz.

  • Hallo, hier Basic-Fan,


    Lysosom, Danke für das Lob.


    Unseen: Das mit dem Loswerden der Zeilennummern ist wohl nur dann möglich, wenn man Quelltext und Programmcode trennt. Und einen eigenen Basic-Codegenerator hat.


    Hoogo: Der Trick wird ja leider nicht standardmäßig von Basic unterstützt.
    Grundsätzlich muß eine Funktion immer erst registriert werden, bevor das Basic sie benutzen kann. Dann ist aber ein Direktsprung ohne Zeilensuche möglich.
    Wenn es in Basic ein FN-END gegeben hätte, wäre es aber denkbar das nach dem Registrieren der Funktion mit DEF das Programm hinter dem FN-END weiterlesen könnte, dann könnten Zeilennummern entfallen.


    Ich persönlich finde die Programmierung mit Zeilennummern allerdings nicht so übel und wenn man in 1ner Schritten nummeriert, statt wie empfohlen in 10ner, hat man auch genügend Zeilennummern zur Verfügung.


    Schönen Gruß, Dirk

  • zeigst du uns jetzt auch den sinnvollen teil dieses "tricks" ? was kann man damit schöner/schneller/eleganter oder überhaupt erst machen das anders garnicht oder nur umständlicher geht?


    und erzähl noch einmal basic wäre lesbar. oder auch nur lesbarer. dieser code ist ein musterbeispiel unlesbaren kauderwelschs.


    Quote

    Auch Unterprogramme mit Funktionen sind möglich.


    keine ahnung was du meinst, aber normalerweise bezeichnet man als funktionsaufruf beim programmieren das aufrufen eines unterprograms inlusive parameter über- und rückgabe. so in etwa:


    Code
    1. a = test(10): print a
    2. end
    3. proc test(n as int) as int
    4. return (n + 10) * 5
  • 1. Also es bleibt nun mal eine Tatsache, daß es Leute mit Basic-Leseschwäche gibt.
    Nennen wir sie einmal die Basic-Legasteniker oder einfach Basic-Nichtprogrammierer.
    Das sind Leute die einerseits behaupten, sie könnten einen Assembler-Hexdump lesen, aber andererseits Basic-Listings nicht lesen oder verstehen können.


    2. Die Frage, nach dem Sinn-Frage des Programms.
    Selbige muß jeder Programmierer immer für sich selbst finden.
    Also welche Befehlsstrukturen setze ich für welche Problemlösung ein.
    Grundsätzlich ist es mit dem PRG möglich mehrere Unterprogramme in einer Basic-Anweisung aufzurufen.


    3. Die Rückgabe von Werten funktioniert mit Variablenzuweisungen.
    Der Interpreter schreibt die Werte der Funktion in die zuletzt zugewiesene Variable.
    Ist also die letzte Anweisung a=a wird die Varialbe a beschrieben.
    Ist die letzte Anweisung b=b wird die Variable b beschrieben.
    usw.


    4. Wie kann der Programmierer die zugewiesenen Werte bestimmen.
    Das funktioniert so, wie von FN her bekannt.


    deffn a(a)=1+0*usr(.)


    Die erzeugten Werte sind also diejenigen, die mit der Berechnung in der Funktion erzeugt werden.
    In dem obrigen Beispiel also 1.


    *Besten Dank auch noch für die 1/4 Stunde des Ruhmes.


    Schönen Gruß, Dirk

  • 1. Also es bleibt nun mal eine Tatsache, daß es Leute mit Basic-Leseschwäche gibt.
    Nennen wir sie einmal die Basic-Legasteniker oder einfach Basic-Nichtprogrammierer.
    Das sind Leute die einerseits behaupten, sie könnten einen Assembler-Hexdump lesen, aber andererseits Basic-Listings nicht lesen oder verstehen können.


    Sagen wir mal, ich zähle mich zu denjenigen, die mit beiden Sprachen hinreichend umgehen können, also sowohl BASIC als auch Assembler sind mir alles andere als fremd.


    Mit deinen "Tricks" kann ich nun wirklich wenig anfangen. Nicht, weil sie nahezu unleserlichen Code erfordern (willst du was verschleiern?), sondern weil sie bar jeden Mehrwerts sind. Ein Trick ist etwas, was andere beeindruckt, weil sie etwas sehen, was sie so noch nie gesehen haben. Da ist das *Können* (das sich auf *Wissen* gründet) ein wichtiger Faktor, aber auch (und gerade beim Programmieren) der *Nutzen*. Den vermisse ich hier. Und in puncto *Können*: da ja niemand (wegen deines Programmier- und Dokumentationsstils) versteht, was du da treibst, kann ich ich nicht wirklich beurteilen, ob du was kannst. *Bewiesen* hast du es noch nicht, nur behauptet.


    Arndt

  • @BASIC-FAN
    Ein Vorschlag!


    Warum fangen wir nicht noch einmal bei null an und vergessen alles, was bis jetzt geschrieben oder gepostet wurde.
    Und versuchen ab jetzt, ganz einfach sachlich, fair und vor allem auch für den einen oder anderen Anfänger den das Thema interessieren dürfte,
    so zu argumentieren und zu erklären damit es auch jeder Anfänger versteht und verwenden kann.


    *Die Hand zum Frieden reicht*