PUBLIC PRIVATE STATIC LOCAL wie benutze ich was am besten?

Beitrag von **Manfred** » Mo, 09. Okt 2006 13:43

Hi,

so, ich mache mal einen neuen Thread auf, damit wir nicht wieder durcheinanderkommen.

Mich würde jetzt einmal folgendes interessieren:

1) Was benutze ich wann/wann nicht und warum, mit welchen Vor und Nachteilen
a) Variablen
PUBLIC
PRIVATE
STATIC
LOCAL

b) Funktionen
STATIC
LOCAL

c) Arrays (was es dazu zu sagen gibt)

Was kann sich warum/wie/wann gefährlich auswirken?

(Ich denke immer wieder an das Beispiel von Hubert, bzw. der Makrovars, die er in locale umgewandelt hat, die dann sehr viel schneller waren)

PS: Wenn jemanden noch etwas einfaällt, dann kann er es ja hier anbringen. Das war jetzt nur der Anfang, der mir adhoc in den Sinn kam.

PPS: Noch etwas: Wenn das Probleme bringt, wie könnte ich sie dann umgehen, bzw. was könnte dann stattdessen besser, oder anders gemacht werden?

Daniel · Beitrag von **Daniel** » Di, 10. Okt 2006 10:34

Gute Frage, Manfred!

Also zu den Variablen meint ein Kollege in unserer XUG, man soll überhaupt keine PUBLIC und PRIVATE mehr verwenden.
Und er tut es auch, es muss also gehen.

Aber umgesetzt habe ich's noch nicht, kann es also noch nicht erläutern.
Bei der Umstellung meiner CLIPPER-Apps in Hybrid-Modus hätte ich nicht drauf verzichten können, da braucht's ganz andere Grundkonzepte.

Beitrag von **Manfred** » Di, 10. Okt 2006 10:42

Hi Daniel,

das ist klar. Ich hatte auch mal vor Jahren einen Mailaustausch mit Hannes Ziegler, in dem er mir erklärte, warum man Public und Privat benutzen kann und evtl. auch soll. Ich habe in meinen Programmen überhaupt keine Public Vars mehr.

Es gibt aber anscheinend auch Tricks, wie man Private Variablen umgehen kann, aber die habe ich noch nicht verstanden. Jimmy hat in einem Thread darüber berichtet. Deshalb habe/hatte ich ja die Hoffnung solche Dinge einmal hier zu bereden und Tipps und Tricks von den anderen zu bekommen.

Allein schon das Wissen, warum welche Art sich wie im Speicher verhält und dementsprechend für Tempogewinn, oder Tempoverlust sorgt, dass ist schon Gold wert. Da gibt es auch diverse Dinge, die zu beachten sind. Aber leider habe ich davon noch keine Ahnung, bzw.arbeitet mich langsam dahin.

Beitrag von **Jan** » Di, 10. Okt 2006 10:52

Ich selber bin gerade dabei eine meiner wichtigsten Anwendungen nach Privates zu durchforsten, die rausfliegen können. Das liegt einfach am Programmierstil, ich habe immer sehr viel mit Variablen in Codeblöcken gearbeitet, und die machen das als Local eben nicht mit (teiweise musste ich bei diesem Prozedere sogar Publics einsetzen!). Zwar wurde dadurch der Code sehr kompakt und übersichtlich, aber die Privates setzten sich eben auch ständig im Speicher fest bzw. mussten zum Modulende händisch "gelöscht" werden. Soweit das eben überhaupt geht.

Einige wenige Publics setze ich noch immer ein. Das sind je nach Anwendung zwischen etwa 2 und 5. Die werden beim Programmstart initialisiert, um global die Bildschirmgröße, die Programmversion, Vodergrund/Hintergrundfarben, oder ähnliche Sachen zur Verfügung zu stellen. Manches davon könnte man sicher auch in eine ini oder soetwas schreiben, damit habe ich mich aber noch nicht befasst, und ich denke die paar Privates werden nicht sonderlich stören.

Statics benutze ich garnicht, habe ich auch noch nie.

Static Functions habe ich noch nie benutzt. Es widerstrebt mir, ein und denselben Funktionsnamen mehrfach zu nutzen. Und nur in einem solchen Fall macht in meinen Augen eine Static Function überhaupt Sinn. Funktionen, die in mehreren Modulen aufgerufen werden landen bei mir in eigenständigen prg, die dann auch nur allgemein verwendete Funktionen beinhalten.

Übrigens: Ich arbeite grundsätzlich niemals mit Prozeduren, immer nur mit Funktionen. Gibt es nichts zum Zurückgeben kann man immer noch ein NIL eintragen. Aber sollte sich im Laufe der Entwicklung ein Rückgabewert erforderlich zeigen, dann muß ich nur das NIL ändern, nicht noch das Procedure zu Function (OK, Kleinigkeit, aber was soll ich mich mit dem Procedure-Function-hinundher abmühen. Ich mache es gerne einheitlich).

Jan

Daniel · Beitrag von **Daniel** » Di, 10. Okt 2006 10:57

Hi Manfred

und wie kommst du ohne Public Vars aus?
Wo hast du all die Grundeinstellungen, Pfade, Farben, Drucker, Fonts (die nicht Standard sind) ...

Beitrag von **Manfred** » Di, 10. Okt 2006 10:58

Hi,

ich versuche Systemparameter so früh wie möglich zu deklarieren und dann eben als max.Private. So sind sie auch dem Rest bekannt und müssen dennoch nicht Public sein.

Das mit den Static Functions habe ich wohl irgendwie falsch verstanden, oder falsch interpretiiert. Werde ich bei Gelegenheit auch wieder ändern und versuchen in Klassen einzubauen.

Mit Ini Dateien tue ich mich schwer, weil die halt von jedermann geändert werden können und dann "BUMM"

PS: Ach so, meine Programmparameter sind in einer Klasse und somit brauche ich dann nur das Objekt "sichtbar" zu machen. Also entfallen alle Variablen rundherum, weil sie ja im Objekt sind.

Beitrag von **Martin Altmann** » Di, 10. Okt 2006 11:09

Oje - das wird bestimmt wieder ein sehr "politischer" Thread

Manfred, gib es ruhig zu: Du willst den Aufstieg schneller schaffen

Ich persönlich schere mich nicht wirklich darum, ob eine Variable local, static, private oder public ist (außer bei Makros, wo es ja nicht anders geht).
In meinem Programm habe ich über 130 publics - also relativ viel.
Aber mein Programm ist eh' ein SDI-Programm und die Fenster sind immer modal - so mache ich mir das Leben recht einfach

Andere nutze nur eine Pbulic-Variable - nämlich ein Array, in dem sie alle Variablen als einzelne Elemente speichern.
Oder auch eine Klasse, die die globalen "Variablen" enthält und definierte Schnittstellen zum Auslesen und (sofern möglich) Ändern.
Was ich gerne mache, ist mit #define zu arbeiten - das erleichtert das Programmieren sehr!
Es ist viel übersichtlicher, MEMVAR->texte[ ort, spr_de ] := "Ort:" zu schreiben (und vor allem später auch wiederzufinden), als MEMVAR->texte[ 9, 1 ] := "Ort:"
Aber das wirst Du Dir ja dann am 28.10. genauer anschauen können

Viele Grüße,
Martin

Beitrag von **Manfred** » Di, 10. Okt 2006 11:18

Hi Martin,

politischer Thread? Nö, denke ich nicht, und wenn werde ich mich nicht beteiligen....

Aufstieg schneller schaffen? Viele Punkt in kurzer Zeit? Ist doch eh egal. Du bist nicht einzuholen, Hubert hat mich schon überholt und ansonsten belege ich einen sehr guten 3.Platz

Zu Publics-> ich denke die sind sehr gefährlich für die Stabilität eines Programmes und sehr speicherhungrig? Also ich weiß jetzt wirklich nicht mehr, was Sache ist. Der eine redet so, der andere so.

(Ich glaube am 4.11. muß Steffen mal gelöchert werden, das er jetzt mal ein Machtwort spricht, was es denn jetzt damit wirklich auf sich hat.)

Was welcher Typ nun macht im Programm, dass ist mir schon klar. Es geht wirklich nur darum, was ist vernünftig? Und was ist lahm und was ist sauschnell?

Wie sieht es mit Membervars aus, oder Methoden? Kann man eine Klasse damit bis zum Erbrechen vollpacken, oder gibt es hier Grenzen, die zu beachten sind?

Beitrag von **Jan** » Di, 10. Okt 2006 11:27

Martin hat geschrieben:Oje - das wird bestimmt wieder ein sehr "politischer" Thread

So schlimm finde ich das garnicht. Hauoptsache das wird keine Glaubensfrage sondern ein friedlicher Austausch der Meinungen und Erfahrungen. Ich freue mich hier mal zu sehen und zu diskutieren, wie andere Entwickler mit dem "Problem" umgehen. Auch wenn es nur so etwas banales ist wie Variablen

Viele von uns sind ja noch lernfähig oder wissbegierig.

Die Sache mit dem einen globalen Array finde ich z. B. ganz interessant. Allerdings macht das in meinen Augen auch alles wieder etwas unübersichtlicher, denn aVar[2, 4] ist etwas nichtssagender als nBildschirmBreite, wenn das irgendwo mitten im Code auftaucht.

Interessant wäre für mich, mal ein paar Beispiele zusehen. Denn ich muß ehrlich gestehen daß ich z. B. nicht den blassesten Schimmer habe wie ich das mit Klassen realisieren sollte. Und damit erschließt sich der Sinn der Sache auch nicht wirklich.

Jan

Beitrag von **Martin Altmann** » Di, 10. Okt 2006 11:29

Hallo Manfred,

Manfred hat geschrieben:politischer Thread? Nö, denke ich nicht, und wenn werde ich mich nicht beteiligen....

das war im übertragenen Sinne gemeint! Politische Diskussionen ufern meist aus - und so ist es mit Deinen Threads auch häufiger - insofern "politisch"

Manfred hat geschrieben:Aufstieg schneller schaffen? Viele Punkt in kurzer Zeit? Ist doch eh egal. Du bist nicht einzuholen, Hubert hat mich schon überholt und ansonsten belege ich einen sehr guten 3.Platz

Na klar bin ich einzuholen - und Hubert, Tom und ich zählen eh' nicht. Solange wir Moderatoren (bzw. Administrator) sind, ändert sich unsere Kategorie nicht...

Manfred hat geschrieben:Zu Publics-> ich denke die sind sehr gefährlich für die Stabilität eines Programmes und sehr speicherhungrig? Also ich weiß jetzt wirklich nicht mehr, was Sache ist. Der eine redet so, der andere so.

Sind sie ja auch - aber wenn man kein verteiltes Arbeiten (parallele Threads, mehrere Fenster parallel,...) hat, kann nicht viel passieren.
Und Geschwindigkeit: in erster Linie reden wir von Datenbankanwendungen, also Datenerfassung! Das langwierigste daran ist die Dateneingabe (das Tippen) - und ob der User beim Wechseln eines Datensatzes 1/10 Sekunde länger warten muss, ist ihm auch egal.

Manfred hat geschrieben:(Ich glaube am 4.11. muß Steffen mal gelöchert werden, das er jetzt mal ein Machtwort spricht, was es denn jetzt damit wirklich auf sich hat.)

Darum machen wir das Treffen ja auch in erster Linie...

Viele Grüße,
Martin

Beitrag von **Martin Altmann** » Di, 10. Okt 2006 11:32

Hallo Jan,

Jan hat geschrieben:Allerdings macht das in meinen Augen auch alles wieder etwas unübersichtlicher, denn aVar[2, 4] ist etwas nichtssagender als nBildschirmBreite, wenn das irgendwo mitten im Code auftaucht.

genau - und darum arbeite ich gerne mit #define. Da kannst Du dann aVar[ Bildschirm, Breite] schreiben...

Viele Grüße,
Martin

Beitrag von **Jan** » Di, 10. Okt 2006 11:45

Hallo Martin,

ja, das hatte ich auch schon so verstanden. Dann wiederum muß ich aber in jede prog vorneeweg ein Bündel an #defines setzen. Das ist eine reine Gefühlssache, aber sowetwas habe ich schon zu Clipperzeiten nie gemocht. Ich habe noch nicht einmal includes benutzt, sondern immer die wahren Werte eingetragen (auch wenn das dann wiederum unübersichtlicher war).

Du siehst, da spielt eine Menge irrationales gefühlsmäßiges Denken mit. Von daher war Dein Einwand der politischen Diskussion sicher gerechtfertigt. Solange wir uns hier nicht um die "richtigen" Gefühle kloppen ...

Der Spruch von Manfred ist da sicher begrüßenswert über die Diskussion mit Steffen. Das wird sicher einiges auf ein solideres Fundament stellen. Aber ich bin mir sicher: Auch danach wird noch immer so einiges Glaubens- oder Gewohnheitsfrage bleiben.

Jan

Beitrag von **Manfred** » Di, 10. Okt 2006 11:55

Hi Martin, Jan,

Glaube, oder Gewohnheit. Ist mir alles Wurscht. (hier jedenfalls

)

Wenn mir jemand die Hand auflegt und sagt: "Mein Sohn, Du bist geheilt", dann ist mir das sch........, Hauptsache ist, ich bin geheilt. Und wenn 1000 Leute kommen und sagen, ohne Medizin kann das gar nicht klappen. (Placebo Effekt)

Wenn mir Beispiele gebracht werden, die mir zeigen, dass ich auf dem Holzweg bin und der andere Weg besser, schneller, oder sonstirgendwie von Vorteil ist, dann werde ich das versuchen.

Ich habe z.B. in meinen alten Clipperprogrammen viele Parameter, oder sonstwas über #define geregelt. Für mich war das nachher zu unübersichtlich. Jetzt erstelle ich eine Klasse mit den entsprechenden Var-Namen und leite sie ab. Mir persönlich gefällt es jetzt besser und ich komme damit hervorragend klar.

@Jan,

Dein Problem, sowas über eine Klasse zu regeln, kan ich jetzt im Moment nicht nachvollziehen. Kläre mich doch mal kurz auf, was Du meinst.

Das mit dem Array, so wie Du es gerade beschrieben hast, ist klar. Mit Array[1,1] oder so ist kein Blumentopf zu gewinnen. Die Zahlen kann man über #define in Namen umwandeln und dann ist es auch einfacher.
#define feldbreite 1

Also z.B. array[1,feldbreite], oder so

PS:sorry, Martin, hattest Du schon erklärt. Wer lesen kann ist klar im Vorteil

Beitrag von **Jan** » Di, 10. Okt 2006 12:23

Manfred hat geschrieben:Dein Problem, sowas über eine Klasse zu regeln, kan ich jetzt im Moment nicht nachvollziehen. Kläre mich doch mal kurz auf, was Du meinst.

Was ich meine ist: Keine Ahnung wie ich soetwas über eine Klasse regeln soll.

Abgesehen davon ist Gewohnheit garnicht so egal. Denn in der Software-Entwicklungen führen eben doch manchmal mehrere Wege nach Rom. Und wenn einer sagt, meine paar Publics stören nicht, ein anderer das über ein Array macht, der dritte über eine Klasse: Dann haben eben alle drei recht. Dann ist es wirklich eine Glaubens-, Gewohnheits- oder Bauchfrage. Bei der keiner unrecht hat. Außer es gibt Probleme Geschwindigkeitsmäßig oder einen Crash. Oder Bandwurmcode, wo keiner mehr durchsteigt, was aber eben auch wieder nur unproduktiv, nicht aber falsch ist.

Jan

Beitrag von **Martin Altmann** » Di, 10. Okt 2006 12:28

Hallo Jan,

Jan hat geschrieben:Oder Bandwurmcode, wo keiner mehr durchsteigt, was aber eben auch wieder nur unproduktiv, nicht aber falsch ist.

ganz im Gegenteil, es ist sogar genau richtig - zumindest, wenn man sich seinen Arbeitsplatz sichern will

Viele Grüße,
Martin

Beitrag von **Manfred** » Di, 10. Okt 2006 12:31

Hi Jan,

hm, das sind alles Dinge, die kann ich bei unserem Treffen mal zeigen. Ich bringe alles mit und führe es einmal vor. Ich schätze dass es bestimmt ein paar andere Meinungen zu meinen Lösungen gibt, die sicherlich interessant sein werden.

Das Problem ist eben noch, dass hier nicht unendlich viel Code veröffentlicht werden kann in einem Rutsch und außerdem finde ich es besser, wenn man sofort mündlich dazu Stellung nehmen kann, weil dann schriftliche Mißverständnisse vermieden werden können.

Aber hier ganz kurz.

Code: Alles auswählen

PROCEDURE main()
Class prgpara FROM datenbank
         VAR cBelegart,;
                nBelegNr
         METHOD initvaria
ENDCLASS
**************************
METHOD prgpara
             cBelegart := "test"
             nBelegNr := 0
RETURN self
************************************************************

oPrgPara := prgpara():new():initvaria()

@ 5, 1 SAY oPrgPara:cBelegart
@ 6, 1 SAY ++oPrgPara:nBelegNr
RETURN

Hilft Dir das vielleicht weiter?

Beitrag von **Jan** » Di, 10. Okt 2006 12:33

Hallo Martin,

so einer bist Du also! Hast Du auch Deine Abfrage auf dem Server, mind. wöchentlich aufzurufen, sonst kommt Komplettformatierung?

Aber ehrlich: Bandwurmcode ist schon falsch. Und kann mich auch meinen Job kosten. Wenn ich nämlich nach einem halben Jahr selber nicht mehr durchsteige was ich da verzapft habe, und dann drei mal so lange brauche für Umarbeiten als eigentlich notwendig. Profilieren kann ich mich doch am besten, wenn ich 5 Minuten nach Auftrag durch Chef das Update anmelden kann

mit dem Gefühl: Ach, was bin ich doch genial!

Jan

Beitrag von **Martin Altmann** » Di, 10. Okt 2006 12:41

Hallo Jan,
nein - keine Sorge, so einer bin ich nicht.
Aber was den letzten Teil Deines Postings anbelangt: mach Dir da mal keine Hoffnungen! Dein Chef sieht das nicht so, wie Du. Der denkt sich: Wenn der nach fünf Minuten fertig ist, dann fahre ich doch billiger, wenn ich ihn Auftragsarbeiten machen lassen, statt ihn fest anzustellen (oder so ähnlich).

Vieel Grüße,
Martin

Beitrag von **Manfred** » Di, 10. Okt 2006 12:45

Hi,

ich wollte es gerade nicht loslassen, aber ich bin der Meinung, man sollte wissen, wie schnell es geht, dabei aber eine ernste Miene machen und erklären was es für ein Aufwand ist, sich ins geheime Kämmerlein verzischen, dort kurz loslegen und den Rest des Tages dann alle 5e von sich strecken.

Beitrag von **Manfred** » Di, 10. Okt 2006 12:47

boh ey,

wir schweifen schon wieder ab....

Beitrag von **Jan** » Di, 10. Okt 2006 12:50

Ich wusste es schon immer. Ich bin zu gut für diese Welt... Und zu naiv...

Jan

Josef Stockinger · Beitrag von **Josef Stockinger** » Di, 10. Okt 2006 15:14

Jan hat geschrieben:
Martin hat geschrieben:Allerdings macht das in meinen Augen auch alles wieder etwas unübersichtlicher, denn aVar[2, 4] ist etwas nichtssagender als nBildschirmBreite, wenn das irgendwo mitten im Code auftaucht.Jan

Warum, geht doch auch so:

Code: Alles auswählen

#define  nBreit     aPublic[01]
#define  nHoch      aPublic[02]
usw..

dann im PRG:

Code: Alles auswählen

PROCEDURE Main()
PUBLIC aPublic[20]     // oder halt die entsprechenden Zahlen

Dann kann man auch die Klarnamen benutzen. Wird wohl auch mit mehrdimensionalem Array gehen, würde ich aber nicht machen.

Auf diesem Weg benutze ich in meinem Hauptprogramm nahezu 1000 LOCAL-Variablen ohne Probleme. Dazu passend habe ich mir eine Verwaltung angelegt, mit der beim Erweitern oder rausnehmen von Variablen automatisch die Nummerierung geprüft und das verwendete Include-File neu geschrieben wird.

Dann wird diese Deklarierung gleichzeitig zur typgerechten Datenübergabe an List&Label benutzt. Das ist übrigens mein Beitrag bei der XUG-Regensburg am 20.Oktober. Könnte schon interessant sein.

Ich sehe keinen Grund, weshalb sich das nicht auf PUBLICs übertragen lassen könnte, habs bisher nur nicht so gemacht, erst diese Diskussion bringt mich drauf. Wenns Sinn macht, bau ich meinen unzähligen PUBLIC mal auf diese Art ein. Ich habe allerdings bisher keine Probleme festgestellt.

Gruß
Josef

Beitrag von **Jan** » Di, 10. Okt 2006 15:40

Hallo Josef,

ja, das war ja auch der Ansatz von Martin.

im Prinzip bin ich damit auch einverstanden, die Idee finde ich auch wirklich sehr gut. Ich muß halt nur am Anfang jeder prg die ganzen #define's auflisten, und damit habe ich ein persönliches, rein gefühlsmäßiges Problem.

Ich muß aber auch gestehen, daß ich manche Probleme von Euch nicht habe, weil ich keine 3thrd-Party-Produkte verwende. Auch kein L&L, eXpress, oder sonstwas. Was wie gesagt einige Eurer Probleme für mich ausklammert, aber natürlich auch andere schafft, wenn ich das alles irgendwie zu Fuß programmieren muß ohne Hilfsmittel.

Jan

Daniel · Beitrag von **Daniel** » Di, 10. Okt 2006 16:04

Manfred hat geschrieben: Zu Publics-> ich denke die sind sehr gefährlich für die Stabilität eines Programmes und sehr speicherhungrig?
Also ich weiß jetzt wirklich nicht mehr, was Sache ist. Der eine redet so, der andere so.

Hi Manfred

wieso sollen Public speicherhungriger sein als Private
und wieso gefährlicher als diese?

So lange ich drei oder vier verschachtelte Functions habe, kann ich Private Vars überall benützen, Local muss ich alle übergeben, das kann ellenlange Parameterlisten geben.

Wenn's aber noch mehr Functions werden, die sich alle dieselben Private Vars teilen, dann kann es unübersichtlich werden.

Beitrag von **Manfred** » Di, 10. Okt 2006 16:26

Hi Daniel,

wenn ich das mal so genau beantworten könnte.

Es ist eine Frage, wie die Public, Private usw. im Speicher verwaltet werden. Auf jeden Fall sind Locale Vars immer schneller als Public, oder Private. Deswegen habe ich ja den Thread hier eröffnet, um das zu klären. Aber ich vermute, richtige Infos werden erst am 4.11. zu Tage kommen. Wie gesagt, da werde ich mal jemanden versuchen zu löchern.

Ich glaube ich mache mir schon mal eine Liste mit Fragen