Hi,
ich denke ich schreibe auch mal was dazu ...
1. Public und Private werden sicher intern gleich gehandhabt, bis auf die Tatsache, dass sich die Sichtbarkeit unterscheidet. Da dürfte sich kein Geschwindigkeitsvorteil/nachteil ergeben (bei Private eventuell wegen der Sichtbarkeitsprüfung - sicher nicht messbar).
-> Allerdings sind Public für allgemein zugängliche Infos und somit noch nicht durch bessere Typen zu ersetzen, da es keine GLOBALs (bei PowerBasic eine Mischung zwischen den Eigenschaften von LOCAL und der Sichtbarkeit von PUBLIC) gibt.
-> Solange ich weiß, dass mein Programm nie in anderer als der alten Clippermanier aufgerufen wird und die Variable immer den 'richtigen' Zustand hat ODER nur READONLY benutzt wird, spricht nichts gegen Public !
=> Also multithreading, oder MDI Fenster oder mehrere Verarbeitungspfade im Programm, verbieten den Einsatz von sich ändernden Publics.
2. Privates wurden bei Clipper (oder war es dBase) eingeführt, als man mehr als nur ein paar Zeilen programmieren wollte, weil es einfach nicht möglich ist ein größeres Programm mit Variablen zu bedienen, die jedes andere Fenster einfach überschreiben kann.
=> LOCALs sind der natürliche Ersatz und in allem besser als Privates und bei GUI (zumindest MDI) und multithreading eigentlich Pflicht.
Wer das nicht meint, handelt sich jede Menge Ärger ein, kann es aber auch schaffen ... schließlich gibt es Leute die zu Fuß nach Rom maschieren, während andere das Auto etc. nehmen.
3. Publics kann man im Programm durch Funktionen mit STATICs (nicht Funktion) ersetzen, während STATICs selbst KEIN Ersatz sind, da sie sich anders verhalten !
Beispiele:
Code: Alles auswählen
statt public cFarbeERR := "w+/r"
nun ? Farben("Fehler") -> "w+/r" // hier schon vorher festgelegt.
oder als Speicher für Programminfos:
function DatenPfad(cPfad)
static cDatPfad := "" // diese Zeile verhindert Warnung
local cReturn
if cPfad=NIL
cReturn := cDatPfad
else
cReturn := cDatPfad := cPfad
endif
return cReturn
im Programm dann beim Programmstart einmalig oder auch später per Menü möglich DatenPfad("c:\daten\") und vor jedem USE (datenpfad()+datei)
Ich verwende selbst in den neuen GUI Programmen keine Publics mehr, sondern nutze solche Funktionen für das Speichern von z.B. Infos aus den INI Dateien. Dies ist aber sicher nicht schneller als eine Public, da der Aufruf von Funktionen langsamer ist.
Wie
Martin aber schon treffend geschrieben hat, solange man nicht in einer 1000fach ausgeführten Schleife ist
spielt es keine Rolle was schneller ist, da ein heutiger Rechner 1000 Operationen pro Sekunde ausführt - selbst VB Programme sind mittlerweile schnell
4. Xbase++ Variablen sind alle langsam !!!
Denn es sind keine streng typisierten Variablen !
Mit PowerBasic oder auch VO kann man eine Variablen typisieren, d.h. vorher festlegen, dass sie eine INTEGER Variable ist und bei PowerBasic sogar, dass sie direkt Prozessorregister nutzen soll. Xbase muß bei jedem Zugriff prüfen, was nun das für eine Variable ist ...
Bei wenigen Aufrufe spielt das keine Rolle, aber eine Schleife mit 2.000.000 oder mehr Durchläufen (ja ich meine soviel 0 ! ) sind diese Sprachen 1000 mal schneller.
Aber dafür haben wir die mächtigeren Befehle, ein aSort() oder dblocate() oder dbseek() arbeitet intern mit anderen Variablen und Methoden und erreicht Geschwindigkeiten die man mit FOR/NEXT (meine Lieblingsschleife) einfach nicht erreichen kann (auch mit PowerBasic ist meine Sortierfunktion langsamer).
Also nicht den Kopf in den Sand stecken oder den Flöhen nachrennen, sondern nur die wirklich entscheidenden Programmteile nach Performance durchforsten und intensiv die mächtigen Befehle bevorzugen.
5. STATICS verwende ich selten, aber sie haben als PRG-weite pseudo golbals ihre Berechtigung. Mein altes Clippermenü verwendete diese für den Flag ob links oder rechts gesprungen werden sollte, nachdem die keyboard ESC+LEFT+ENTER bzw. ESC+RIGHT+ENTER nicht mehr zu handln war.
und gegen den Rest läßt sich auch nichts sagen 
