XPSE

Deutsch

Dieter
Zornow

XPSE meldet bei folgendem Code einen Fehler, Profan meckert nicht Inspector
auch nicht, der Code läuft auch einwandfrei Nur XPSE meldet "undeclariert a&".

Ich nehme doch stark an, was ja auch die Praxis beweißt, dass in einer
Unterproc einer Prozedur die Variablen der Prozedur dort bekannt sind.

Wer macht hier den Fehler Profan und der Inspector weil zu tolerant oder
XPSE
Kompilieren Markieren Separieren

Proc Dialog

    Proc zeige

        print a&

    endproc

    var a& = 10
    zeige()

endproc

cls
dialog()
waitinput

Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2

06.12.2008 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Jupp, ein Bug in einem Feature. Bug tritt bei Declare und Var auf.

XPSE kann die "Sichtbarkeit" von Variablen bei Funktionsverschachtelungen prüfen und hierauf Unterschiede anwenden.

Dem XPSE geht es ja eben darum, weniger lose Anforderungen zu setzen, da "lose" Anforderungen ja bereits durch XProfan selbst abgedeckt werden.

So wie dieser Code
Kompilieren Markieren Separieren

Gemerkt/Separiert von http://xprofan.com/thread.core?t=7218

Proc Dialog

    test{

        print aqe+1

    }

    long aqe=10
    test()

endproc

cls
dialog()
waitinput

sollte auch Dein Code durchlaufen.

Den Fehler behebe ich natürlich, dankesehr!

06.12.2008 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Dieter
Zornow

Die "losen" Anforderungen sind aber wichtig, da ich z.B nicht in
XPSE - Syntax programmiere und auch nicht die Sachen wie auf Headerdateien
verzichten nutze. Ich will bewußt, dass meine Codes unter XProfan lauffähig
bleiben. Ich nemutze XPSE höchstens mal zur Codeüberprüfung
und dann ist es ja witzlos wenn ich wegen den "losen" Sachen noerror einschalten
müsste.

Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2

06.12.2008 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

In diesem Fall gibt es mehr Abhilfen, als z.B. "nur" {$noerr}.

Beispielsweise könntest die Variablen-Deklaration über die Funktions-Deklaration setzen, oder mit {$pushkeyword a&} arbeiten.

Auf jeden Fall ist es aber so, dass ein "xpse-konformer" Code, auch nachvollziehbar "valide" sein soll, wenn man nunmal nicht unterstellt, das ein loser Interpreter diesen versteht.

Der Konstrukt
Kompilieren Markieren Separieren

proc a

    proc b

        print c&

    endproc

    var c&=1
    b

endproc

mag von XProfan korrekt ausgeführt werden, mehr aber auch nicht.

XPSEs Vorgaben orientieren sich nunmal nicht daran, ob XProfan es wohl möglich korrekt "ausführt", sondern daran, dass XProfan es definitiv korrekt ausführt.

Diese "erkaufte" Sicherheit ist natürlich nicht für jeden interessant, mal abgesehen davon, dass ein "Bug" diesen von Dir beschriebenen Fehler verursacht.

06.12.2008 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Hallo,

Dieters Code wird nicht nur korrekt ausgeführt, er ist auch definitiv und sicher korrekt!
Wenn XPSE anderer Meinung ist, dann ist XPSE nicht 100%ig kompatibel zu XProfan.

Die Sichtbarkeit von Variablen wird in unterschiedlichen Sprachen nun mal unterschiedlich gehandhabt. XProfan hält es mit der Sichtbarkeit von Variablen sehr ähnlich wie Pascal (-> TuboPascal -> Delphi). Eine "oberhalb" einer Prozedur definierte Variable ist innerhalb der Prozedur bekannt, es sei denn, es ist innerhalb der Prozedur zuvor eine gleichname (lokale) Variable deklariert worden. (Hierbei gilt das Parameters auch als deklaration von Variablen.)
Die Variable a& in Dieters Beispiel ist daher in der PROC zeige bekannt, da sie oberhalb dieser deklariert wurde. Das würde in Pascal und seinen direkten Abkömmlingen bis hin zu Delphi genauso funktionieren.
In C und dessen Nachfahren, wozu ich jetzt mal sehr großzügig auch C++ und Java zähle) würde es so nicht funktionieren.
(Und in PowerBasic war es noch ganz anders, da mußte man übergeordnete Variablen mit "shared" in die Prozedur übernehmen.)

An dieser Stelle ein Tipp für Anwender von Profan2CPP: Da hier C++-Code erzeugt wird, sollte man in diesem Fall derartige Konstrukte allerdings vermeiden und auf verschachtelte Prozeduren verzichten.

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

06.12.2008 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Hallo,

Dieters Code wird nicht nur korrekt ausgeführt, er ist auch definitiv und sicher korrekt! Wenn XPSE anderer Meinung ist, dann ist XPSE nicht 100%ig kompatibel zu XProfan.

100%ig kompatibel zu XProfan kann XPSE nicht sein, da XPSE viel mehr über den Code grübelt, als es für XProfan notwendig ist.

06.12.2008 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren