XPSE

- Seite 5 -

Dietmar
Horn

Klar - irgendwie hast Du damit ja auch recht.

Ich verwende diese Vorgehensweise aber gelegentlich trotzdem, weil XProfan (leider) keinen Compilerschalter für bedingte Compilierung kennt, wie das in anderen Programmiersprachen der Fall ist.

Gruß
Dietmar

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]

28.02.2005 ▲

Hi, iF!
[quote:75c6004837]
Folgendes steht nämlich einer sauberen Programmierung entgegen:

if 1
proc pla
endproc
else
proc pli
endproc
endif
[/quote:75c6004837]
Spräche eigentlich etwas gegen folgende Vorgehensweise - ohne den Schalter {$nosectioncheck}?

if 1
pla
else
pli
endif

In dieser Konstellation werden die Prozeduren pla und pli doch nur anstelle eines (längeren) Quelltexts eingesetzt, um für mehr Übersicht zu sorgen.
Oder betrifft das nur den Fall, wenn ich pla und pli in einer INC unterbringen würde?

Gruß, Christian

XProfan 8/9.1, Win XP, AMD 64/3200

28.02.2005 ▲

Es geht nur um die Deklarierung von Prozeduren innerhalb von ifs[whiles[repeats[etc...]]] - nicht um das Ausführen von Prozeduren.

Folgendes beachtet XPSE und meldet ggf. einen...

Sektionsfehler:
Kompilieren Markieren Separieren

if
proc

endif

endproc

if
proc

endproc

endif

proc
if
endroc

endif

while
if

wend

endif

Es geht einfach darum das XPSE etwas strenger als XProfan-selbst ist - damit sich weniger Fehler in den Source schmuggeln können.

Salve, iF

28.02.2005 ▲

Dietmar
Horn

Hallo David,

XPSE V0.1.3.p findet Incude-Dateien nicht, wenn dahinter bis zum Zeilenende ein Kommentar steht.

Ohne Kommentar werden die INCs jedoch gefunden.

Gruß
Dietmar

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]

Der Sache nehme ich mich gleichmal an.

Hm, ich teste grade

$I input.inctest

und da gibz nix Fehler.

Auch bei
Kompilieren Markieren Separieren

 $I inputtest
 $I input//test
include inputtest
#include inputtest
include input//test
#include input//test

läuft nix schief.

Ahhh, ich sehe bei
Kompilieren Markieren Separieren

include input/*test
*/
oder
 $I input/*test
*/

gibbed den Fehler - meinst Du das?

Also das /* */ Rem macht Fehler bei Compilerschaltern hmpf

Kla - gehört korrigiert.

Salve, iF

Jauix.

Dat Teil is schlimmeliger als ik dachte.

Et betrifft die gesamten compilerschalter welche nicht mit /* */ ausklammerbar sind.

Das Prob ist das ich in diesem Schritt aller Operationen nicht einfach das RemKilling ansetzen kann - da die Strings an der Pos (beim Einladen in dem Mem) noch freigelegt sind.

Dat wird grauselig...acker...

Salve, iF

Dietmar
Horn

Hallo David,

folgendes klappt bei mir:

$I C:VEREINDHOXPROFAN9FORTSCHRITT.INCTEST

und das auch:

$I C:VEREINDHOXPROFAN9FORTSCHRITT.INC TEST
(Hochkamma durch Leerzeichen abgetrennt)

Wenn ich jedoch das Hochkamma durch einen Tabulator abtrenne - nur dann funzt es nicht mehr.

Dietmar

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]

Verstehe - is heut noch behoben.

Salve, iF

Dietmar
Horn

Danke,

nun klappt es endlich wieder!

Aufgefallen ist mir das eigentlich erst im Zusammenhang mit dem Compilerschalter für die bedingte INC-Einfügung mit darin enthaltenen PROCS.

Den Compilerschalter hierfür halte ich nach wie vor für überflüssig, genau wie die strengere Syntaxüberprüfung in diesem Punkt.

Meiner Meinung nach sollte es nicht die Aufgabe eines Programmautors sein, die Anwender seiner Software in irgendeine Richtung herumerziehen zu wollen. Meistens läuft das sowieso gegen den Baum (siehe GOTO-Diskussion, oder über die Sache mit mehreren Befehlen in einer Zeile im RGH-Forum).

Solange es in XProfan keinen richtigen Compilerschalter für bedingte Compilierung gibt, hat diese Vorgehensweise meiner Meinung nach ihre Berechtigung: Was z.B. in einer Testversion gar nicht erst im Code drin ist, das bläht das Programm nicht unnötig auf (und kann auch gar nicht erst gecrackt werden).

Dietmar

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]

Du ich weiß nicht genau was Du meinst.

XPSE soll auch niemanden erziehen - es geht darum die Fehler eines Sources auffindig zu machen um maximale Interpretationsgenauigkeit zu Produzieren.

Beim Proggen gibt es strenge Regeln - aber was erzähl ich Dir.

Es ist sicher falsch wenn ein Compiler folgendes erlaubt:

proc
if
endproc
endif

da nicht vorhersehbar ist wied er Code von PRFVersion zu Version interpretiert wird. Es ist also unklar - was wiederum gegen jede Form der Programmierung spricht.

Aber ich glaube darum gings Dir nicht - ich habe Dich wohl nicht richtig verstanden.

Salve, iF

Dietmar
Horn

Hallo David,

ich schätze, da haben wir beide jeder ein bißchen recht - oder uns tüchtig mißverstanden.

Als vorläufigen Ersatz für bedingte Compilierung meinte ich lediglich eine Konstruktion in folgender Art:

if testversion%
proc pla mit Inhalt 1
endproc
else
proc pla mit Inhalt 2 <> Inhalt 1
endproc
endif

oder notfalls:

if testversion%
proc pla
endproc
else
proc pli
endproc
endif

wobei dann beim Aufrufen der PROCs natürlich ebenfalls nochmals eine IF-ELSE-ENDIF-Abfrage auf testversion% erforderlich wäre, die nicht angemeckert werden dürfte. Das sollte auch beim Verwenden von XPSE erlaubt bleiben.

Jedenfalls, solange es in XProfan noch keine andere Möglichkeit für (echtes) bedingtes Compilieren gibt ...

Die anderen von Dir genannten Konstruktionen sollten natürlich auch weiterhin von XPSE angemeckert werden, solange RGH bzw. sein Compiler das nicht selber macht.

Gruß
Dietmar

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]