Wie empfindlich reagiert Xbase auf Public und Private Var's?

[mini990]

Hallo,
da ich einige Variablen systemweit benutze würde ich diese gerne als Public deklarieren.
Geschwindigkeitsprobleme?

Desweiteren wären einige Private-Variablen aus Bequemlichkeitsgründen interessant.
Geschwindigkeitsprobleme?

danke im voraus

Gruß Stefan

[brandelh]

Hallo,

in einer älteren Anwendung, welche aus Clipper 1 zu 1 umgesetzt wurde habe ich auch privates und publics in Verwendung. Wenn du sie nicht als Zählschleife bei einer ewig langen Schleife verwendest, dürfte ein Geschwindigkeitsunterschied gar nicht messbar sein.
Ob lokals schneller sind als privates oder publics weiß ich nicht, aber die Probleme liegen auf anderer Ebene.

Ein Clipper-Programm und ein Xbase++, welches sich genauso verhält, kann leicht die Kontrolle über public und private behalten, dennoch soll es schon vorgekommen sein, dass unerwünschte Nebeneffekte aufgetreten sind, weil der Programmierer die Übersicht verlor.

Bei einem GUI Programm kann man mit privates vielleicht noch leben, aber bei static und public muß man immer wissen, dass der Anwender entscheidet wann er was macht, 2 Fenster könnten sich gegenseitig also die Werte verändern und der Anwender wundert sich.

Noch schlimmer wird es wenn mehrere Threads in der Anwendung existieren.
Es kann Sinn machen z.B. eine globale Variable für einen unveränderlichen Systempfad etc zu haben, aber man muß höllisch aufpassen dass der Code keine Nebenwirkungen hat.

In zukünftigen Versionen (so habe ich das mal vor Jahren aufgeschnappt) könnte auch eine Optimierung in Xbase eingebaut werden, welche zur Compilierzeit numerische Variablen erkennen kann, welche nur einen Integerzahlenbereich benötigen. Eine solche Optimierung in einer Zählvariablen wäre enorm und würde nur mit local funktionieren.

Ob diese aber jemals kommt ?

[mini990]

Hallo Hubert,
ich verwende nur sehr wenige Publics die bis auf eine einzige Ausnahme statisch sind.
Mit den Privates verhält es sich eher so, daß ich sie in der Regel für Statics verwende und mir einfach den Tippaufwand der Übergabe ersparen will......
Die Kanten und Ecken bei Publics sind noch aus Clipper-Zeiten bei Anwendungen im Netzwerk bekannt...

Gruß Stefan

[Armin]

Hallo Stephan,

ich hatte schon lange keine Probleme mehr mit PUBLIC-Variablen und benutze sie in einigen Programmen ausgiebig

Die in Clipper bekannten Probleme mit Symboltabellen, die zu gross wurden hatte meistens mit dem begrenzten Speicher unter DOS zu tun.

Klar ist der Speicherbedarf einer Symboltabelle vor dem Programmstart nicht vorhersehbar und kann eventuell zu Engpässen führen.

Gruss, Armin

[arthur]

Hallo,

auch ich bin ziemlich faul, was das declarieren von local Variablen betrifft. Im Zweifelsfall verwende ich dann oft publics. Sicherlich, man muss höllisch aufpassen, vor allem, wenn man mit mehreren threads arbeitet, aber ich habe bisher keine Probleme gehabt, obwohl ich eine Anwendung mit 10 paralell laufenden threads habe und darin sicherlich 80-100 publics verwende.
Einen Geschwindigkeitsnachteil kann ich auch nicht feststellen, da einer meiner threads alle 10 Millisekunden externe Hardware abfragt und ich noch nie Probleme damit hatte.

Gruß Arthur

[Lewi]

Hi,
Aufgrund der eingeschränkten Symboltabellen unter Clipper, hatte ich mir es angewöhnt, innerhalb der Programme ausschließlich mit einer Public-Variablen zu arbeiten. Diese Variable ist ein Array und kann innerhalb des Codes über Define-Deklarationen angesprochen werden.

Code: Alles auswählen

#define     _PROGRAM_ID			m->_p_[ 1]
#define     _SYSTEMINIFILE		 m->_p_[ 2]
#define     _THREADACTIV		m->_p_[ 3]
#define     _CARGO			    m->_p_[ 4]
#define	   _LENPUBLICARRAY      4

Procedure Main

Public _p_ := Array(_LENPUBLICARRAY)

_PROGRAM_ID			:= 1234
_SYSTEMINIFILE		:= „c:\prog/prog.ini”
_THREADACTIV		:= .F.	

[brandelh]

Das Hauptproblem von Privat und Public Variablen ist nicht die Geschwindigkeit (auch wenn ich mal gehört habe, dass später local vars über automatische Optimierung schneller werden sollen - bis jetzt ist davon nichts zu merken) sondern die Nebenwirkungen, wenn in mehreren Threads oder Programmteilen gleiche Funktionen aufgerufen werden.

Insbesondere wenn man diese Routinen auch noch mit anderen austauscht (gleiche Namen von local und private etc.) sind Wechselwirkungen vorprogrammiert. Vor kurzem hat im Alaska Forum jemand bei folgendem Code Probleme gehabt (aus dem Gedächtnis):

xNR := recno()
...
xNR++ // hier kam ein Fehler stringvariable kann nicht ++ werden ...

nach längerem Raten wurde dann folgender ergänzende Code, aufgerufen in einer multithreaded Anwendung herausgegeben:

function ....
static xNR
...
xNR := recno()
...
xNR++ // hier kam ein Fehler stringvariable kann nicht ++ werden ...
...
xNR := str(xNR)
... er meinte die Reihenfolge wäre doch eindeutig ... unter clipper wäre sie dies wohl auch gewesen. Ich sage immer man kann sich das Leben auch leicht machen und mache alles local, es sei denn ich habe einen guten Grund es anders zu machen.

Wenn man das beachtet, kann man diese schon benutzen.
Auch READ-ONLY Felder z.B. mit Druckersteuercodes in meinen alten Clipperprogrammen, oder Standardpfade kann man so einfach ablegen.