Als nicht übergebenen Parameter holt sich Profan einfach die Variable aus der übergeordneten Funktion - ist doch logisch - oder???
Allermerkwürdigste Fehler........
-
-
-
@P.Specht
ZitatKann man daraus schließen, daß Variablen, die vorher "woanders" deklariert wurden, eben berücksichtigt werden, wenn sie nicht durch lokale Variablen gleichen Namens verdeckt sind? Das wäre dann zumindest irgendwie verständlich, oder?
So ungefähr könnte man XProfan wohl beschreiben. Wobei ich für "woanders" aber eher formulieren würde "bei der Abarbeitung schon mal gesehen". Prozeduren können ja in XProfan auch schon vor ihrer Deklaration aufgerufen werden. Profan 7 und früher lag da näher an anderen Sprachen, zumindest in Bezug der Sichtbarkeit von Prozeduren. Bei Variablen weiß ich das jetzt nicht so genau, habe gerade keine 7er Version zur Hand.
Gruß Volkmar
Perfekt, Roland hat es ganz konkret beschrieben, nun sollte es auch eindeutig klar sein.
-
Zitat von p. specht;836009
Stimmt, parametes a$ und dann Declare a$ steht schon in AHT`s Beispiel drin... Sorry Frank!
Geht erst ab Version 10 nicht mehr - vorher lief der Code wunderbar.
Versuch das mal:Code
Alles anzeigenProc Foo2 Parameters a& Print "Foo2 Anfang: a="+Str$(a&) a&=007 Print "Foo2 Mitte: a="+Str$(a&) 'Declare a& a&=1147 Print "Foo2 Ende: a="+Str$(a&) EndProc Proc Foo1 Parameters a& Print "Foo1 Anfang: a="+Str$(a&) Foo2 Print "Foo1 Ende: a="+Str$(a&) EndProc Cls Foo1(4711) WaitKey
Als nicht übergebenen Parameter a& holt sich hier Foo2 das a& von Foo1.
Es wird damit aber eine neue Variable angelegt - ist das in anderen Sprachen auch so???
Ist eigentlich logisch - wenn man nichts übergibt, holt man sich das was da ist und backt was neues draus... Oder verhält sich der Code in neueren Versionen ebenfalls anders? -
Ah ja, stimmt. Wieso der Aufruf von foo2 ohne parameter überhaupt gelingt, obwohl in der proc mit parameters a$ einer verlangt ist, ist tatsächlich ein Rätsel...
Nebenbei ein Wunsch: Das Wort "Parameters " ist einfach zu lang.
Param oder Parm oder ein Simples "Get " wären schöner, noch schöner wären einfach die in Basic üblichen Klammern: proc foo(a$,a&,a%) .. endproc -
Und noch was ...
Code
Alles anzeigenProc Foo2 Parameters b& Print "Foo2 Anfang: b="+Str$(b&) a&=007 Print "Foo2 Mitte: a="+Str$(a&) 'Declare a& a&=1147 Print "Foo2 Ende: a="+Str$(a&) EndProc Proc Foo1 Parameters a& Print "Foo1 Anfang: a="+Str$(a&) Foo2 Print "Foo1 Ende: a="+Str$(a&) EndProc Cls Foo1(4711) WaitKey
Wer kann das logisch erklären????
Variable b& nimmt hier den Wert von Parameter a& aus Foo1 an... -
-
Wenn mein Code oben (hatte noch einen Fehler drin) weiterhin noch so wie von mir beschrieben funktioniert, würde ich folgende Erklärung geben:
XProfan ist eine sehr ordentliche Programmiersprache! Wenn sie irgendwo Müll liegen sieht und gerade die Taschen leer hat, packt sie sich den Müll in die leere Hosentasche und recycled den (damit nichts verloren geht) .
Es kann natürlich durchaus sein, dass auch alle anderen interpretierenden Sprachen in dieser Art Müll von der Straße sammeln - wer weiß ;).
[Blockierte Grafik: http://s4.postimage.org/aar7cokk/Parameterfehler.jpg] -
@P.Specht
ZitatAh ja, stimmt. Wieso der Aufruf von foo2 ohne parameter überhaupt gelingt, obwohl in der proc mit parameters a$ einer verlangt ist, ist tatsächlich ein Rätsel...
Prozeduren können mit einer unterschiedlichen Parameterzahl aufgerufen werden und es bleibt Dir überlassen, ob Du die verwendest und wenn ja, wie viele.Zitatnoch schöner wären einfach die in Basic üblichen Klammern: proc foo(a$,a&,a%) .. endproc
Würde mir auch besser gefallen. Aber da könnte ich in jeder Sprache was finden, was mir nicht unbedingt gefällt. Warum darf ich eigentlich in PureBasic eine Messagebox nicht Messagebox nennen? Nur mal so ein Beispiel. So hat eben jede Sprache ihre Eigenheiten.@AHT
ZitatWer kann das logisch erklären????
Variable b& nimmt hier den Wert von Parameter a& aus Foo1 an...
Habe ich noch nie probiert. Aber mal mit Rolands Beschreibung weiter oben kann ich dann ungefähr sowas ableiten:
Es werden so viele Parameter vom Stack gelesen, wie die Prozedur abrufen will. Und wenn gar keiner da ist, dann gerät man eben an die Parameter des Vorgängers.Gruß Volkmar
-
-
@P.Specht
Schon verstanden. Der Code bringt es nun auf den Punkt. War vor dem Aufruf noch gar keine andere Parameterübergabe und es ist zuvor auch nirgendwo eine Variable deklariert, dann wird's bedenklich. Es wird dann wohl wirklich was gelesen unter der Position, wo die erste Variable stehen würde, wenn es sie denn gäbe? Und das ist dann wahrhaftig nicht mehr gut.Gruß Volkmar
-
Nun, ich muß zugeben, dass ich einfach vergesse zu überprüfen, ob ausreichend Parameter vorhanden sind. Deshalb meckert er ein Parameters nicht an, auch wenn keiner (oder zu wenige) übergeben werden. Zur Übergabe der Parameter an Prozeduren nutze ich intern ein Array in der Größe der maximalen Parameterzahl. Und da steht dann wohl noch der Parameter vom letzten Aufruf drin und wird dann genommen.
Ich sollte vielleicht eine Überprüfung einbauen und den Programmierer auf seinen Fehler hinweisen ...
Gruß
Roland -
Ich habe zwar noch nie wissentlich Parameter abgerufen, die nicht da sind, bin heute hier erstmalig mit der Frage konfrontiert worden. Aber es wäre nett, wenn da irgendwann mal ein Hinweis käme, wenn da was nicht stimmt.
Gruß Volkmar
-
Namens der DAU-Gemeinde: Danke für Euer Engagement!
P.S.: Vielleicht eine Gelegenheit, sich für "parameters" ein zusätzliches Kürzel einfallen zu lassen. Und Proc 7 .. endProc mit Aufruf 7( ) ist vermutlich auch nicht gerade zukunftssicher programmiert
-
Funktionsnamen sollten immer mit A-Z, a-z oder _ beginnen, da sollte mal eine
Überprüfung rein.Desweiteren sollte das Vererben von Variablen innerhalb von Funktionen gestoppt werden.
Das wird bei der Weiterentwicklung von XProfan ansonsten noch richtig zum
ProblemDas mit den Namen kann mir zwar sowieso nicht passieren (werde auch nie
Umlaute nutzen) aber das mit der Variablenvererbung kann in grösseren
Funktionen schon zu Fehler führen, weil man denkt, sie wäre Lokal (in der
Funktion bereits deklariert) aber dem ist garnicht so und es meckert keiner -
Zitat von ts-soft;836095
Funktionsnamen sollten immer mit A-Z, a-z oder _ beginnen, da sollte mal eine Überprüfung rein.
Da stimme ich fast zu. (Und ab dem 2. Zeichen wären dann noch zusätzlich Ziffern, Punkt und Dollar erlaubt.) Die entsprechende Funktion ist auch schon in XProfan enthalten, wird aber nicht genutzt. Der Aufschrei wegen der Incompatibilität zu älteren Quellcodes wäre zu laut!
Zitat von ts-soft;836095Desweiteren sollte das Vererben von Variablen innerhalb von Funktionen gestoppt werden.
Wie meinst Du das? Gar keine globalen Variablen mehr und grundsätzlich Übergabe über Parameterleiste? Oder globale Variablen ausschließlich im Hauptprogramm, was der lexikalischen Sichtbarkeit entspräche. Letzteres fände ich auch nicht schlecht, aber die Kompatibilität ....
Möglicherweise wird ein künftiges XProfan derartiges ermöglichen, dann aber einn Compilerschalter enthalten, der den Kompatibilitätsmodus einschaltet.
Gruß
Roland -
Zitat von RGH;836136
Wie meinst Du das? Gar keine globalen Variablen mehr und grundsätzlich Übergabe über Parameterleiste? Oder globale Variablen ausschließlich im Hauptprogramm, was der lexikalischen Sichtbarkeit entspräche. Letzteres fände ich auch nicht schlecht, aber die Kompatibilität ....
Globale Variablen im Hauptprogramm schon, aber in Proc definierte sollte
nicht in anderen Proc wie globale Variablen funktionieren, sondern gar nicht
existieren. Dieses komische Vererben eben.Dann wäre es natürlich sinnvoll, für das Hauptprogramm auch lokale Variablen
zu ermöglichen, z.B. Protect a$, oder Lokal a$.Der nächste Schritt wären dann Statische Variablen, die Ihren Wert bei
jedem Proc-Aufruf behalten! Das macht viele globale Variablen überflüssig
und sollte gerade in grösseren Projekten von Vorteil sein.Zur Kompatibilität: Das Vererben per Compilerschalter an und aus, der Rest
ist Neu oder kompatibel. -
Zitat von ts-soft;836141
Globale Variablen im Hauptprogramm schon, aber in Proc definierte sollte nicht in anderen Proc wie globale Variablen funktionieren, sondern gar nicht existieren. Dieses komische Vererben eben.
Da könnte ich mit leben, obwohl ich auch schon mal Proc in Proc geschrieben habe. Für diesen Fall wäre es dann ja eindeutig, dass die innere Proc alles sieht, was die umschließende Proc vor der inneren Proc-Deklaration schon an Variablen deklariert hat. Aber man kann nicht alles haben. Wenn's nicht ginge, dann ginge es eben nicht. Man kann's ja mal probieren, so lange es nicht verboten ist.
Zitat von ts-soft;836141Der nächste Schritt wären dann Statische Variablen, die Ihren Wert bei jedem Proc-Aufruf behalten!
Eine hervorragende Idee. Das würde ich mir wünschen. Macht in der Tat Einiges einfacher.
Gruß Volkmar
-
Zitat
Eine hervorragende Idee. Das würde ich mir wünschen. Macht in der Tat Einiges einfacher.
Aber das weicht zu viel von der Norm ab und wäre dann eine fiese Fehlerquelle.
-
Hallo Frank
So große Probleme sehe ich da gar nicht mit Static-Variablen. Das wäre ja was Neues und würde Bestehendes nicht ändern. Ich mache da dann innerhalb einer Prozedur ausdrücklich Declare Static a% oder wie auch immer. Die bisherige Form Declare a% bleibt erhalten und ändert nichts am Verhalten der Variablen. Damit läuft alles wie bisher und wer nichts mit Static anfangen kann, der benutzt es eben nicht.
Recht hast Du auf jeden Fall, wenn nun plötzlich alle Variablen innerhalb einer Prozedur immer Static sind. Das würde in der Tat dicke Probleme bringen und wäre auch nicht mein Wunsch. Das würde dann ja bedeuten, dass jedesmal ein Clear für jede Variable nötig wäre, die ich in bisheriger Weise nutzen will.Gruß Volkmar
-
Als Zusatz macht das natürlich gleich mehr Sinn.
Du kannst den Vorschlag ja mal bei den Anregungen posten. Wenn es soweit ist, findet Roland die neuen Vorschläge einfacher.
Dann steigt deine Beitrags-Anzahl auch mal. Ich finde es immer verwirrend zu sehen, dass du noch 0 Beiträge hast, obwohl du dich hier sehr fleissig beteiligst. Aber im Stammtisch werden Beiträge ganz einfach nicht mitgezählt. -
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!