| |
|
|
Dieter Zornow | XPSE meldet chez folgendem Code une faute, Profan meckert pas Inspector aussi pas, qui Code fonctionne aussi einwandfrei seulement XPSE meldet "undeclariert a&".
je prends doch stark à, quoi oui aussi qui Praxis beweißt, dass dans einer Unterproc einer Procédure qui Variablen qui Procédure là bekannt sommes.
qui pouvoir ici den faute Profan et qui Inspector weil trop tolerant ou bien XPSE KompilierenMarqueSéparation |
|
|
|
|
| Jupp, un Bug dans einem Feature. Bug tritt chez Déclarer et Var sur.
XPSE peux qui "Sichtbarkeit" de Variablen chez Funktionsverschachtelungen vérifier et hierauf Unterschiede anwenden.
Dem XPSE ca va oui plan tout autor, moins lose Anforderungen trop mettons, là "lose" Anforderungen oui bereits par XProfan selbst abgedeckt volonté.
So comment cette Code KompilierenMarqueSéparation |
|
|
|
|
Dieter Zornow | qui "losen" Anforderungen sommes mais important, là je z.B pas dans XPSE - Syntax programmiere et pas qui Sachen comment sur Headerdateien verzichten nutze. je veux bewußt, dass mon Codes sous XProfan courir rester. je nemutze XPSE au maximum la fois zur Codeüberprüfung et ensuite ist es oui witzlos si je à cause de den "losen" Sachen noerror einschalten devrait. |
|
|
| 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 ▲ |
|
|
|
|
| dans diesem le cas gibt es plus Abhilfen, comme z.B. "nur" {$noerr}.
Beispielsweise könntest qui Variablen-Deklaration sur qui Funktions-Deklaration mettons, ou bien avec {$pushkeyword a&} travailler.
sur jeden le cas ist es mais so, dass un "xpse-konformer" Code, aussi nachvollziehbar "valide" son soll, si on nunmal pas unterstellt, cela un loser Interpreter cette versteht.
qui Construire KompilierenMarqueSéparation mag de XProfan korrekt fonctionnement volonté, plus mais aussi pas.
XPSEs Vorgaben orienter sich nunmal pas daran, si XProfan es wohl possible korrekt "ausführt", mais daran, dass XProfan es définitif korrekt ausführt.
cet "erkaufte" Sicherheit ist naturellement pas pour jeden intéressant, la fois abgesehen en, dass un "Bug" cette de Dir beschriebenen faute verursacht. |
|
|
| |
|
|
|
RGH | Salut,
Dieters Code wird pas seulement korrekt fonctionnement, il est aussi définitif et sûrement korrekt! si XPSE anderer attitude ist, ensuite ist XPSE pas 100%ig kompatibel trop XProfan.
qui Sichtbarkeit de Variablen wird dans unterschiedlichen Sprachen eh bien la fois unterschiedlich gehandhabt. XProfan hält es avec qui Sichtbarkeit de Variablen très ähnlich comment Pascal (-> TuboPascal -> Delphi). une "oberhalb" einer Procédure definierte Variable ist dedans qui Procédure bekannt, es sei car, c'est dedans qui Procédure zuvor une gleichname (lokale) Variable deklariert worden. (Hierbei gilt cela Paramètres aussi comme deklaration de Variablen.) qui Variable a& dans Dieters Beispiel ist daher dans qui PROC zeige bekannt, là vous au-dessus de cette deklariert wurde. cela serait dans Pascal et seinen direkten Abkömmlingen jusqu'à hin trop Delphi genauso marcher. dans C et dessen Nachfahren, wozu je maintenant la fois très großzügig aussi C++ et Java zähle) serait es so pas marcher. (et dans PowerBasic était es encore entier anders, là mußte on übergeordnete Variablen avec "shared" dans qui Procédure prendre.)
à cette Stelle un Tipp pour Anwender de Profan2CPP: là ici C++-Code erzeugt wird, sollte on dans diesem le cas derartige Konstrukte allerdings vermeiden et sur imbriquées Prozeduren verzichten.
Salut 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
Salut,
Dieters Code wird pas seulement korrekt fonctionnement, il est aussi définitif et sûrement korrekt! si XPSE anderer attitude ist, ensuite ist XPSE pas 100%ig kompatibel trop XProfan.
100%ig kompatibel trop XProfan peux XPSE pas son, là XPSE viel plus sur den Code grübelt, comme es pour XProfan notwendig ist. |
|
|
| |
|
|