Xpp
XPP ist der Compiler von Alaska Software Inc.
Die Compiler Schalter
/? -> zeigt eine Information über die Compilerschalter und die installierte Xbase++ Version am Bildschirm an. Kann nicht mit anderen Schaltern kombiniert werden. /a -> hiermit werden alle mit PRIVATE, PUBLIC oder PARAMETERS spezifizierten Variablen als MEMVAR deklariert /b -> hiermit werden Debug Informationen eingebunden um im Debugger XPPdbg, oder in der VX ablaufende Programme genauer untersuchen zu können. /coff -> /com -> /d<id>[=<val>] -> /dll[:DYNAMIC] -> /err:<count> -> /es -> /ga -> /go -> i<path> -> /l -> /link[:"options"] -> /m -> /n -> /nod -> /o<name> -> /omf -> /p -> /pptrace -> /profile -> /q -> /r<libname> -> /s -> es wird nur die Programmsyntax geprüft, aber keine OBJ Datei erzeugt. /u[<name>] -> /v -> /w -> es werden Warnungen angezeigt, wenn der Compiler auf nicht deklarierte Variablen, oder Feldvariablen ohne Aliasbezeichnungen stößt* /wi -> es werden Warnungen angezeigt, wenn der Compiler auf nicht initialisierte Variablen stößt, die aber eigentlich einen Wert haben müßten* /wl -> es werden Warnungen angezeigt, wenn der Compiler auf nichtlexikalische Variablen stößt.* /wn -> /w -> /wu -> es werden Warnungen angezeigt, wenn der Compiler auf nicht benutzte lexikalische Variablen stößt, die deklariert wurden, aber nicht in Benutzung sind. (Ermöglicht es, den Code schlank zu halten)* /z -> Short-Cut Optimierung.
- diese Compilerschalter können dem Entwickler sehr viel Arbeit abnehmen. Bei sauber programmiertem Code, sollten diese Schalter keine Meldungen erzeugen. Dies hat den Vorteil sehr schnell Schreibfehler usw. zu entdecken, bevor das Programm an den Endanwender ausgeliefert wird und dort evtl. für Probleme sorgt. Deshalb kann nur wärmstens empfohlen werden, diese Schalter einzusetzen.
Detaillierte Erklärung
/w Standard-Warnungen bezüglich Variablen
Dieser Schalter gibt eine Warnung bezüglicher verwendeter Variablen aus, die nicht
- via LOCAL oder STATIC oder FIELD definiert sind,
- bzw. nicht durch einen Alias explizit auf ein Dateifeld verweisen.
Im Umkehrschluss werden Variablen, die mittels PUBLIC oder PRIVATE deklariert sind, bei Verwendung als Warnung gelistet.
Betrachten wir folgende Funktion:
FUNCTION SwitchW(nWert) IF nWerl > 12 RETU(.F.) ENDIF RETURN (.T.)
Durch einen Schreibfehler wurde aus nWert nWerl - da sich "t" und "l" recht ähnlich sind, kann das auch bei einer visuellen Kontrolle des Codes nicht auffallen. Der Compiler-Switch /w prüft aber, ob verwendete Variablen auch deklariert wurden:
XPPDEMO.PRG(5:0): warning XBT0102: Ambiguous variable reference nWerl
/wi Warnung bei der Verwendung nicht initialisierter Variablen
Betrachten wir folgenden Code:
FUNCTION Main() Local nEvent, mp1, mp2, oXbp nEvent := xbe_None WHILE !nEvent <> xbeP_Close nEvent := AppEvent(@mp1, @mp2, @oXbp) oXbp:handleEvent(nEvent, mp1, mp2) END RETURN (.T.)
Klassischer Code, wie wir ihn auch in den Dokumentationsbeispielen finden. Der Compiler-Schalter /wi produziert folgende Warnungen:
XPPDEMO.PRG(5:0): warning XBT0120: LOCAL variable mp1 may not have been set before first use XPPDEMO.PRG(5:0): warning XBT0120: LOCAL variable mp2 may not have been set before first use XPPDEMO.PRG(5:0): warning XBT0120: LOCAL variable oXbp may not have been set before first use
Der Compiler kann an dieser Stelle nicht erkennen, dass die Verwendung hier "harmlos", da die Variablen nur als Platzhalter für Rückgabewerte dienen.
Während das vorhergehende Beispiel harmlos ist, sieht das hier anders aus:
FUNCTION SwitchWI() Local nTest IF nTest < 12 RETU(.F.) ENDIF RETURN (.T.)
XPPDEMO.PRG(21:0): warning XBT0120: LOCAL variable nTest may not have been set before first use
An dieser Stelle wird die Verwendung von nTest zu einem Laufzeitfehler führen.
/z Short-Cut Optimierung
Die Short-Cut Optimierung führt dazu, dass verknüpfte Abfragen nur so lange ausgeführt werden, bis klar ist, dass die Bedingung erfüllt oder nicht erfüllt ist.
WHILE (cArg1 > cArg2) .OR. (cArg3 > cArg4) // tue irgendetwas END
Wenn cArg1 > cArg2 ist, beendet der Schalter /z die weitere Prüfung, da aufgrund der .OR.-Bedingung die Schleife weiter ausgeführt wird, auch wenn der zweite Vergleich cArg3 > cArg4 falsch wäre.
nArg1 := 0 nArg2 := 5 WHILE nArg1++ < 5 .OR. nArg2-- > 0 // tue irgendetwas END
Mit dem Auswerten der Ausdrücke wird gleichzeitig die betreffende Variable verändert. Es ergibt sich folgendes Verhalten, abhängig von der Short-Cut Optimierung:
Durchlauf | nArg1 | nArg2 | nArg1 | nArg2 |
---|---|---|---|---|
1 | 1 | 5 | 1 | 4 |
2 | 2 | 5 | 2 | 3 |
3 | 3 | 5 | 3 | 2 |
4 | 4 | 5 | 4 | 1 |
5 | 5 | 5 | 5 | 0 |
Die ersten Spaltengruppe nArg1/nArg2 bezieht sich auf aktivierte Short-Cut Optimierung, die zweite Spaltengruppe nArg1/nArg2 bezieht sich auf de-aktiviert Short-Cut Optimierung.
Ist die Short-Cut Optimierung aktiv, wird nach Ausführen der ersten Abfrage festgestellt, dass der Vergleich WAHR ist, also wird die zweite Abfrage nicht ausgewertet, und damit entfällt die Veränderung der Variablen nArg2.
Ist die Short-Cut Optimierung nicht aktiv, werden beide Abfragen ausgeführt und beide Variablen in jedem Durchlauf verändert.