| |
|
|
Dieter Zornow | XPSE meldet bei folgendem Code einen Fehler, Profan meckert nicht Inspector auch nicht, der Code corre 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 KompilierenMarkierenSeparieren |
|
|
|
|
| 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 KompilierenMarkierenSeparieren |
|
|
|
|
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 ▲ |
|
|
|
|
| In diesem Fall gibt es mehr Abhilfen, als z.B. "nur" {$noerr}.
Beispielsweise könntest die Variablen-Deklaration circa 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 KompilierenMarkierenSeparieren mag von XProfan korrekt corsa werden, mehr aber auch nicht.
XPSEs Vorgaben orientieren sich nunmal nicht daran, ob XProfan es wohl possibile korrekt "ausführt", sondern daran, dass XProfan es definitiv korrekt ausführt.
Diese "erkaufte" Sicherheit ist naturalmente nicht per jeden interessant, mal abgesehen davon, dass ein "Bug" diesen von Dir beschriebenen Fehler verursacht. |
|
|
| |
|
|
|
RGH | Ciao,
Dieters Code wird nicht nur korrekt corsa, 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 per Anwender von Profan2CPP: Da hier C++-Code erzeugt wird, sollte man in diesem Fall derartige Konstrukte allerdings vermeiden und auf verschachtelte Prozeduren verzichten.
Saluto 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 ▲ |
|
|
|
|
| RGH
Ciao,
Dieters Code wird nicht nur korrekt corsa, 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 circa den Code grübelt, als es per XProfan notwendig ist. |
|
|
| |
|
|