lokale Variablen mit globaler Lebensdauer?

[sniper_w]

Zitat:

...zum Thema "globale Variablen vermeiden": gibts denn in Object Pascal lokale Variablen mit globaler Lebensdauer? (C/C++ Stichwort "static")

mfg

Ich habe damasl diese Frage auf meine Festplatte geschpeichert, wollte es später auch beantworten. Da ich erst jetzt diese Frage wieder gefunden habe, hier ein Antwort: Ja.
Und zwar so(Delphi 6):

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
{$IFOPT J-}
  {$DEFINE restore_me}
{$ENDIF}
{$IF DEFINED (restore_me)}
  {$J+}
{$IFEND}
const D:Integer = 0;
{$IF DEFINED (restore_me)}
  {$J-}
{$UNDEF restore_me}
{$IFEND}
begin
  Inc(D);
  Caption := IntToStr(D);
end;

Für weitere Erklärungen, siehe OH.

[Luckie]

Nein, das ist ein Missbrauch von Konstanten und entspricht nicht dem Schlüsselwort static von C/C++. Das funktioniert übrigens auch nur noch, weil es Borland aus Kompatibilitätsgründen nicht rausgeschmissen hat. Als Programmierer sollte man so etwas tunlichts vermeiden, da es einfach nicht sauber programmiert ist, denke ich.

[Dax]

Ums direkt zu sagen: Lokale Variablen mit Globaler Lebensdauer sind größtmöglicher Schwachsinn. Da kannst du auch gleich globale Variablen nehmen, was genauso schwachsinnig ist ;)

[Robert Marquardt]

Das ist nur Schwachsinn wenn man es wie im Titel formuliert.
Richtig heisst es globale Variablen mit lokaler Sichtbarkeit. Das ist es was C hat und Delphi nicht.
Variablen in der implementation section sind aber fast genauso gut.

[Sprint]

Eine andere Möglichkeit um auf die Compiler Direktive WRITEABLECONST ($J) zu verzichten:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
const
  Counter: Integer = 0;
begin

  Inc(PInteger(@Counter)^);
  Caption := IntToStr(Counter);

end;

[NicoDE]

Zitat:

Zitat von Sprint

Eine andere Möglichkeit um auf die Compiler Direktive WRITEABLECONST ($J) zu verzichten:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
const
  Counter: Integer = 0;
begin

  Inc(PInteger(@Counter)^);
  Caption := IntToStr(Counter);

end;

Eine schlechte Idee schlägt die nächste :)

sniper_w: dein Quellcode macht Probleme wenn 'restore_me' vorher bereits definiert wurde...

[Sprint]

Zitat:

Zitat von NicoDE

Eine schlechte Idee schlägt die nächste

Soll nur zeigen, das sowas möglich ist...

[s.h.a.r.k]

Mal ne Frage: Zu was brauche ich das?! Ich kann in Delphi doch globale und lokale Variablen festlegen wie ich will und ich weiß doch von vorne rein, was global und lokal sein soll?! Was bringt mir das dann?

[sniper_w]

Zitat:

Als Programmierer sollte man so etwas tunlichts vermeiden, da es einfach nicht sauber programmiert ist, denke ich.

Zitat:

Ums direkt zu sagen: Lokale Variablen mit Globaler Lebensdauer sind größtmöglicher Schwachsinn. Da kannst du auch gleich globale Variablen nehmen, was genauso schwachsinnig ist

Darüber lässt sich diskutieren. Aber das wollte ich ja nicht. Ich wollte lediglich diese Möglichkeit zeigen. Ob das richtig ist, schön oder nicht, ist eine andere Sache.

[sniper_w]

Zitat:

Zitat von NicoDE

sniper_w: dein Quellcode macht Probleme wenn 'restore_me' vorher bereits definiert wurde...

Dann musst du halt aufpassen ;). Anstatt 'restore_me', nimm 'TForm1_Button1Click_Sender_TObject_'

[NicoDE]

Zitat:

Zitat von sniper_w

Dann musst du halt aufpassen ;)

Wenn ich aufpassen würde, dann würde ich keine schreibbaren Konstanten verwenden :)

[Robert Marquardt]

Zitat:

Zitat von s.h.a.r.k

Mal ne Frage: Zu was brauche ich das?! Ich kann in Delphi doch globale und lokale Variablen festlegen wie ich will und ich weiß doch von vorne rein, was global und lokal sein soll?! Was bringt mir das dann?

Man hat eine globale Variable die nur in genau einer Funktion zugreifbar ist. Das verhindert Probleme beim Programmieren.
In C liefert man auch ganz gerne einen Zeiger auf eine globale Variable als Funktionsergebnis. Dder Inhalt bleibt dann bis zum naechsten Funktionsaufruf gueltig.

[Sidorion]

Vergiss am besten OOP und programmiere (nein falsch wurschtle) mit turbo3 oder AnsiC (oder noch besser: GW-Basic).
Wer solche Sachen in einer OO-Programmiersprache macht gehört imho dazu verdonnert, den Rest seines Lebens Druckertreiber zu schreiben.
Entschuldige die rüde Wortwahl, aber wenn ich sowas sehe, stellen sich mir die Fußnägel hoch.
Mal abgesehen davon wozu zum Teufel brauchst Du solch eine lokal sichtbare globalvariable??????????????
Wenn Du sowas brauchst, dann definiere Dir eine Variable im implementation teil einer extra unit, in der auch Deine Funktion drinne ist. Den Header der Funktion lässt Du dann rausschauen .. und voilà das Ganze ohne Rumgefummel mit Defines (noch dazu Missbrauch von Compilerschaltern).
J ist dazu da, älteren Code mit neueren Delphi Versionen übersetzen zu können und nicht damit man Konstanten manipulieren kann!

[Robert_G]

Zitat:

Zitat von Sidorion

Wer solche Sachen in einer OO-Programmiersprache macht gehört imho dazu verdonnert, den Rest seines Lebens Druckertreiber zu schreiben.

Schön gesagt. :)

Zitat:

Zitat von Sidorion

Wenn Du sowas brauchst, dann definiere Dir eine Variable im implementation teil einer extra unit, in der auch Deine Funktion drinne ist. Den Header der Funktion lässt Du dann rausschauen .. und voilà das Ganze ohne Rumgefummel mit Defines (noch dazu Missbrauch von Compilerschaltern).

Klingt wie ein *piep*-normales Singleton, right? :zwinker:

[sniper_w]

Üblicherweise sollte man alle Postings lesen bevor man antwortet, und nicht so blind und wutend reagieren, als wurde man beraubt oder irgend wie direkt verletzt.

OT: Viele sind so mit einem OP (Win oder Linux oder sonst was) geblendet, dass sie keine Ausführbare Datei mehr produzieren könnten, wenn Win (oder sonst...) plotzlich von der Szene verschwunden würde...
Bitte Antwortet ihr nicht, dieses Thema ist ünnotig mehr.

[Robert_G]

Zitat:

Zitat von sniper_w

Üblicherweise sollte man alle Postings lesen bevor man antwortet, und nicht so blind und wutend reagieren, als wurde man beraubt oder irgend wie direkt verletzt.

Hmm.. ich finde das Prinzip an sich nicht sehr sinnvoll.
Man kann dir ja eigentlich nur vorwerfen, dass du jemandem ermöglicht hast typisierte Konstanten zu nehmen, der es alleine nicht auf die reihe gekriegt hätte. Einen wirklichen Vorwurf kann man das also nicht nennen.
Der, der abdrückt ist Schuld. Nicht der, der ihm zeigt wie man schießt. ;)

[DGL-luke]

Zitat:

Zitat von Robert_G

Der, der abdrückt ist Schuld. Nicht der, der ihm zeigt wie man schießt. ;)

worüber man diskutieren könnte... aber das wäre dann ja doch ein wenig off topic.

aber ich finde sowas auch absolut schwachsinnig. wozu denn bitte sehr?

[dizzy]

Es gibt noch ne andere Variante, die ich z.B. beim CQParser verwende:

Delphi-Quellcode:

function foo: PInteger;
var
  i: PInteger;
begin
  GetMem(i, SizeOf(Integer));
  i^ := 12345;
  result := i;
end;

So in etwa. Klassen die man lokal erzeugt, aber nicht mehr frei gibt sind sozusagen dann auch weiter da, nur wird der Pointer darauf beim Verlassen des Blocks zerstört. Übergibt man den Pointer hingegen vorher an eine Variable die über den Block hinaus besteht, so ist darüber ganz normaler Zugriff möglich, und auch eine ordentliche Freigabe. Das wäre meiner Meinung nach noch die sauberste Variante dieser kleinen Schweinerei :D.

[negaH]

Hi,

ich werde mich mal outen und entgegen allen anderen Aussagen hier behaupten: das vorinitialisierte und globale Variablen die nur lokal für eine Funktion sichtbar sind eine konsequente Fortsetzung der modularen Programmierung ist. Ergo: sie sind restriktiver und vermeiden gegenüber normalen globalen Variablen eine Fehlbenutzung im restlichen Code. Sie sind also aus meiner Sicht absolut guter Programmierstil.

Behauptungen wie "globale Variablen" seien Blödsinn und wer sie benutzt gehört "erschossen" sind unkonstruktiv und sogar noch dümmlich falsch. Denn alle Variablen eines Programmes sind aus Sicht der CPU immer auch global. Der einzigste Unterschied für uns zwischen globalen, lokalen, lokal globalen oder Feldern eines Objects als Variablen ist nur deshalb vorhanden weil der Compiler/Sprache so programmiert wurde. Es sind also reine Festlegungen, bzw. Definitionen die unsere Art und Weise zu programmieren verbessern sollen. Ein wichtiges Kriterium von N.Wirth bei der Schaffung von PASCAL war die Idee der "Restriktionen". D.h. die Festlegung von klaren Schnittstellen in die Programmiersprache.

Wenn nun eine globale Variable in ihrem Wirkungsbereich global zu allen Funktionen einer Unit ist, sie aber tatsächlich nur in einer einzigsten Funktion einer Unit benutzt wird, dann ist es ein guter Programmierstil durch absichtliche Restriktionen im Sichtbarkeitsbereich dieser Variablen dafür zu sorgen das es zu keinen Fehlern in der Programmierung kommen kann. Nun, eine statische Variable in einer lokalen Funktion, sprich eine globale Variable nur definiert im Gültigkeitsbereich der lokalen Funktion ist eine konsequente Fortführung des Gedankens der Restriktivität, absolut sauberer Programmierstil.

Statt auf Delphi 9/10 zu warten mit mehr versprochenen Features in der Programiersprache oder sich auf pauschale Aussagen wie "OOP ist gut, globale Variablen sind kein OOP und deshalb schlecht" sollte man einfach mal versuchen das Hirn vorher einzuschalten und einfach mal logisch solche Aussagen analysieren, statt irgendwelche Meinungen wiederzukauen.
Mich stört es ungemein das es offentsichtlich einen Trend gibt der dazu führt das man Glaubenskriege über die bessere Programmiersprache oder -Stil führen kann. Die offensichtliche Grundlage solcher Diskussionen ist die Überbewertung der einzelnen Sprache/Stiles so als wären es wertvolle Dinge. Nein, es sind nur Werkzeuge die wir selber erschaffen haben. Sie basieren auf Vorstellungen von einzelnen Leuten die nicht richtig oder nicht falsch sein müssen. Der einzigst relevante Unterschied in den Sprachen ist deren Konzept auf dem sie basieren. Nun, und PASCAL basiert auf der Restriktion, der Restriktion einen String nicht wie einen ordinalen Integer benutzen zu können, der Restriktion die Sichtbarkeit von Datenobjekten, eben Variablen auf das nötigste zu beschränken. Führt man diesen Gedanken weiter so kommt man auch irgendwan auf globale Variablen deren Gültigkeit global ist aber deren Sichtbarkeit lokal auf diese eine Funktion beschränkt wurde. Was, liebe Leute, soll daran falsch sein ?

Wie gesagt: Ich oute mich und wenn es Sinn macht dann benutze ich erst recht solche globalen Variablen mit eingeschränkter Sichtbarkeit. Einfach weil es eine sinnvolle Funktionalität darstellt.

Gruß Hagen

[Robert_G]

@Dizzy
Nur wann braucht man mal einen einzelnen primitiven Wert? :gruebel:
Um mehrere, zusammengehörige Werte zu einem Paket zu verschnüren, das nur einmal existieren darf, wäre das klassische Singleton wohl die gebräuchliste Lösung. ;)

Delphi-Quellcode:

interface

type
   TSingletonDings = class
   private
      function getSomeValue: TSomeType; virtual; abstract;
      procedure setSomeValue(const aValue: TSomeType); virtual; abstract;
   public
      property SomeValue: TSomeType read getSomeValue write setSomeValue;
      class function Instance: TSingletonDings;
   end;

implementation

uses
   ...;

type
   TRichtigesDings = class(TSingletonDings)
   private
      fSomeValue: TSomeType;
      fAllowDestruction: Boolean;
      function getSomeValue: TSomeType; override;
      procedure setSomeValue(const aValue: TSomeType); override;
   public
      destructor Destroy; override;
   end;

var
   staticDings     : TRichtigesDings;

{ TSingletonDings }

class function TSingletonDings.Instance: TSingletonDings;
begin
   Result := staticDings;
end;

{ TRichtigesDings }

destructor TRichtigesDings.Destroy;
begin
   if fAllowDestruction then
      inherited
   else
      raise InvalidSingletonDestructionException.Create(TSingletonDings);
end;

function TRichtigesDings.getSomeValue: TSomeType;
begin
   Result := fSomeValue;
end;

procedure TRichtigesDings.setSomeValue(const aValue: TSomeType);
begin
   fSomeValue := aValue;
end;

initialization
   staticDings := TRichtigesDings.Create();
   staticDings.fAllowDestruction := False;
finalization
   staticDings.fAllowDestruction := True;
   staticDings.Free();
end.

Delphi-Quellcode:

TSingletonDings.Instance.SomeValue := Miep;

@Hagen
Sicher ist es widerlich eine Variable anlegen zu müssen, die über die ganze Unit sichtbar ist... :?
Aber solange dort effektiv nur eine Klasse definiert ist, ist es zwar hässlicher als ein statisches Feld, aber genauso einsetzbar.
Innerhalb einer Klasse würde ich Sichtbarkeiten nicht mehr unterteilen wollen. Schließlich sollte man genau wissen was man da gerade macht und ein anderer (bzw. man selbst ein paar Wochen später) kann sich innerhalb einer auch nicht so leicht in den Fuss schiessen.
Bis Delphi32 statische Felder bekommt (statische Variablen in einer funktion finde *ich persönlich* sinnlos...), müssen wir mit dem leben was wir haben.
Typ. Konstanten sind hauptsächlich deshalb problematisch, da sie vielleicht einen lieben Tages keine Unterstützung des Compilers mehr erfahren werden (sie sind bereits jetzt per default nicht erlaubt).
.Net kennt solche Konstrukte noch nicht einmal! (Also statische lokale Variablen)
Auf kurz oder lang wird es das also nicht mehr geben. Warum sollte man es also jetzt noch jemandem zeigen? :gruebel:

Oh und bevor jetzt jemand aufschreit dass es in managed C++ geht: Bitte vorher den IL Code ansehen. :shock:
Aus...

Code:

public: 
   void Miep()
   {
      static int x = 4;

      x++;
   }

...wird dann...

Code:

public static int ?x@?1??Miep@Comp1@CppClassLib@@Q$AAMXXZ@4HA;

Code:

public void Miep()
{
   ?x@?1??Miep@Comp1@CppClassLib@@Q$AAMXXZ@4HA++;
}

...und das dürfte wohl in keinster Weise restriktiv sein. ;)

[dizzy]

Zitat:

Zitat von Robert_G

@Dizzy
Nur wann braucht man mal einen einzelnen primitiven Wert? :gruebel:
Um mehrere, zusammengehörige Werte zu einem Paket zu verschnüren, das nur einmal existieren darf, wäre das klassische Singleton wohl die gebräuchliste Lösung. ;)

Aus Gründen der Gleichbehandlung (Geschwindigkeit) von Konstanten und Variablen in meinem Parser (die selbst definierten) war das sinnvoll. Ich habe es dort im Übrigen nicht nur mit primitiven Werten, sonder auch mit Records (:shock:) so gemacht ;). Und es durfte nicht nur ein mal existieren. Ein Singleton wäre nicht nur nicht angebracht gewesen, sondern mit einem Overhead verbunden der nicht gerechtfertig wäre.

[negaH]

Argumente wie:

- das wird es nicht mehr geben
- Borland wird es in seinem Compiler nicht mehr unterstützen
- es ist ein schlechter Stil
- schau dir mal andere Sprachen an
- in Sprache X ist das aber möglich
- mit Objekten sollte man Singeltons benutzen

zählen rein garnichts. Im Delphi gibt es initialisierte Konstanten die wie statische Variablen auch lokal zu einer Funktion benutzt werden können. Das ist der Stand der Dinge über den wir reden.

Aber aus solchen Argumenten eine Begründung zu konstruieren warum die Benutzung solch einer Funktionaltiät ein schlechter Programmierstil darstellt ist unlogisch und irrwitzig.

Schau mal, ich meine das ein guter Programmierstil reingarnichts damit zutun hat ob man bestehende Funktionalität einer Programmiersprache nun so oder so benutzt. Ich habe in meinen 20 Jahren die ich als Programmierer garbeitet habe viel Software gesehen. Interessant sind natürlich nur die Projekte die auch ihr gestecktes Ziel erreicht haben. Und dabei musste ich feststellen das guter Programmierstil in Assembler, Basic, Pascal, C und sogar VBA möglich ist, ohne oder mit OOP, ohne oder mit Interfaces, rein procedural oder eben nicht. Das dieser gute Stil Programme sein konnten die Spaghetti Code waren, oder fast schon kryptische C Sourcen oder eben OOP in Pascal.
Ich habe aber auch schon Software gesehen die den vergeblichen Versuch unternommen haben wirklich alles OOP konform in Klassen zu kapseln, und?, dadurch ist der ReportBuilder auch nicht besser geworden als andere viel einfachere Lösungen. Wer den RB gekauft hat sollte sich wirklichmal in dessen Source einarbeiten.

Ehrlich gesagt, ich bewundere Sources bei denen jede einzelne Sourcezeile wirklich zum Gesamtwerk beiträgt, alles ist durchdacht, angefangen beim benutzten Algorithmus der auf handfesten mathematischen Berechnungen beruht, über die richtige Wahl der effizientesten Datenstrukturen (was auch einfache Records sein könnten) über diereale Umsetzung als Source bis hin zur fertigen Software. Dabei war es im Grunde egal mit welcher Sprache programmiert wurde und/oder welchen Stil der Programmier sich angeeignet hatte (hauptsache dieser Stil war sauber strukturiert).
Wichtig ist dann nur eine Aussage: "Wow das hat der Programmierer ja genial gelösst!"

Das heist also das ein Programmierer der einen guten Programmierstil besitzt mit JEGLICHEM Werkzeug immer einen guten Stil haben wird, egal welche Programmiertechnologien ihm zur Verfügung stand. Das wichtigste Indiz für einen guten Stil ist nicht die Beschränkung auf eine geringe Menge aller Möglichkeiten einer Sprache, sondern das wichtigste Indiz ist die effiziente und an das Problem angepasste Verwendung ALLER Möglichkeiten einer Programmiersprache.

Die Aussagen das OOP, .NET etc. pp. DEN besten Stil in der Programmierung darstellen sind also meiner Meinung nach eine sehr kurzsichtige und aufdoktrierte Sichtweise der Dinge. Eine solche Sicht muß zwangsläufig in eine Idiotie führen, denn man versperrt sich die unvoreingenommene Sicht auf all die anderen möglichen Wege eine Software zu programmieren. Mann was haben wir nicht alles in den letzten Jahren an Trends kommen und wieder sterben sehen. Was ist eigentlich aus Kylix geworden, was aus Corba, was aus dem Extreme Programming. Alles ist gescheitert weil mehr die Marketingexperten das sagen hatten, weil die Mode in die Programmierung Einzug gehalten hat, und mit der Mode kamen die überflüssigen Mode-Schöpfer in unsere Branche. Wir streben nach immer neueren Sprachfeatures weil man glaubt dadurch dann ein besserer Programmierer zu werden. Ich erinnere mich an ein simples Problem hier in der Delphi Praxis: bau die Lottoziehungen im Fernsehen als Program nach. Es hat mich viele Postings gekostet um auf das eigentliche Problem aller Lösungsvorschläge hinzudeuten, es verständlich zu machen. Nämlich das Erkennen des eigentlichen Problemes um die korrekte Lösung zu finden, und nicht der beste Weg zu irgendeiner halbrichtigen Lösung.

Schau mal: ich programmiere in ganz verschiedenen Sprachen auf ganz verschiedenen Plattformen. Zb. Delphi auf PC's, C/C++/Pascal auf Handhelds, C/Asm auf Mikrokontrollern und VHDL/ABEL auf FPGA's/CPLD's. Alles hat mit Programmierung zu tun, keine der unterschiedlichen Sprachen oder Plattformen lässt einen direkten Vergleich untereinander zu, sie sind zu verschieden. Und denoch behaupte ich das wenn ich dir einen Source in Delphi für PC's und einen Source in C/Assembler für zb. einen Atmel Mikrokontroller zuschicke du denoch einen Stil EINER Person in der Art der Programmierung erkennen wirst. Wie bitte schön passt da OOP als Methode der Programmierung hinein ?
Ich behaupte mal das man den ausgeprägten Stil eines Programmieres auch "durch die Sprache hindurch" wiedererkennen kann. Die Sprache, ja selbst die unterschiedlichen Methoden des Programmierens, ist zur Bewertung eines Programmier-Stils absolut irrelevant. Es geht viel mehr um Kreativität, wie ein Mensch ein Problem erfassen konnte, wie dieser Mensch seine Aufgaben organisiert, welches Wissen er dafür verwendet und ihm zur Verfügung steht, und ob er zeilstrebig diszipliniert und sauber arbeiten kann. Erst danach kommt die Technologie in Form seiner Werkzeuge zum tragen, sprich die Programmiersprache.

Ihr verwechselt den Programmierstil mit äußeren Umweltbegingungen, irgendwelchen Gegebenheiten irgendwelcher Sprachen oder bestimmter Technologien, irgendwelchen vorgekauten Meinungen von Mode-Schöpfern. Wie zb. Microsoft pusht .NET also muß es gut sein, Borland forciert OOP also ist es guter Stil. Shit sage ich dazu nur, den der Programmierstil ist allerhöchsten vergleichbar mit dem schriftstellerischen Schreibstil eines Buchautors oder mit der Pinselführung und Farbauswahl eines Malers.

Gruß Hagen

[Robert_G]

Kann es sein, dass du mal wieder genau das herausgelesen hast, was du herauslesen wolltest? :gruebel:

[NicoDE]

Zitat:

Zitat von Robert_G

Kann es sein, dass du mal wieder genau das herausgelesen hast, was du herauslesen wolltest? :gruebel:

Tun wir das nicht alle ?-)

Ich finde die ursprünglich geschriebe Lösung viel zu umständlich. Es ist, meiner Meinung nach, unnötig die Compiler-Flags zu aktivieren und deren ursprünglichen Zustand wieder herzustellen. Ein {$WRITABLECONST ON} in der Unit hätte ausgereicht um das Sprach-Feature zu ermöglichen (und dem lesenden/benutzenden Entwickler mitzuteilen, dass er darauf achten sollte). So muss man erst den gesamten Quelltext lesen um die Abhängigkeiten festzustellen (und sich daran erinnern, was verdammt noch mal der Compiler-Schalter J war :)).
Eine Unit ist ebenso ein geschlossenes Gebilde wie eine Funktion, Objekt oder Procedure. Insofern kann man sich darüber streiten, ob die Compiler-Flags im jeweiligen Fall in der Funktion oder in der Unit stehen sollten (Geschmacksfrage...).

[DGL-luke]

Zitat:

Zitat von Robert_G

Kann es sein, dass du mal wieder genau das herausgelesen hast, was du herauslesen wolltest? :gruebel:

Könnte es sein, dass du mal wieder keine begründungen lieferst für deine behauptungen? :gruebel:

ich würde hagen hier zustimmen: auch prozedurale programmierung kann sauber sein. OOP ist ein schönes modell, das sich mit seinen restriktionen gerade dafür eignet, dass nicht alle im team alles über die arbeit der anderen weiss.

wer aber eine schöne prozedurale unit schreibt und seine funktionen und records schön kommentiert, wird auch nicht mehr verwirrung stiften.

und vor allem macht OOP sehr viel mehr arbeit als prozedurale programmierung. zumindest meines Ermessens(kann auch daran liegen, dass bei mir OOP bis jetzt mit "Komponentenprogrammierung" äquivalent ist und ich da noch nicht ganz durchsteig).

[Robert_G]

Zitat:

Zitat von DGL-luke

Zitat:

Zitat von Robert_G

Kann es sein, dass du mal wieder genau das herausgelesen hast, was du herauslesen wolltest? :gruebel:

Könnte es sein, dass du mal wieder keine begründungen lieferst für deine behauptungen? :gruebel:

Warum sollte ich erklären, was ich meine. Du scheinst einfach nur nicht alles verstanden zu haben.
Und was ich mit dieser letzten Frage meinte, war eher dass Hagens (gewöhnlich) langer Beitrag IMHO fehl am Platz war, da das Thema gar nicht wirklich aufkam...

Zitat:

ich würde hagen hier zustimmen: auch prozedurale programmierung kann sauber sein.

Was ist denn das für ein Argument? :gruebel:
a) Ging es hier überhaupt nicht darum und b) ist ein "X kann doch auch OK sein" in etwa so aussagekräftig wie auf alles mit 42 zu antworten. :roll:

Zitat:

Zitat von DGL-luke

und vor allem macht OOP sehr viel mehr arbeit als prozedurale programmierung.

Wieder so ein Ding, das hier absolut OT ist und schnell in einem Krieg angepupter Nicht-OOP'ler ausartet...

Zitat:

Zitat von DGL-luke

zumindest meines Ermessens(kann auch daran liegen, dass bei mir OOP bis jetzt mit "Komponentenprogrammierung" äquivalent ist und ich da noch nicht ganz durchsteig).

Was sagst du, wenn ich dir nun vorwerfe, dass du für fast keine deiner Aussagen eine Begründung geliefert hast?
Ehrlich gesagt interessiert es mich nicht wirklich. Es ging mir nur darum, dass du mir erst etwas vorwirfst, was du im selben Beitrag selbst machst... :gruebel:


btw: @Nico
Jupp, ich glaube das tun wir wohl alle... ;)

[malo]

Zitat:

Zitat von DGL-luke

ich würde hagen hier zustimmen: auch prozedurale programmierung kann sauber sein. OOP ist ein schönes modell, das sich mit seinen restriktionen gerade dafür eignet, dass nicht alle im team alles über die arbeit der anderen weiss.

wer aber eine schöne prozedurale unit schreibt und seine funktionen und records schön kommentiert, wird auch nicht mehr verwirrung stiften.

Da stimm ich dir auch vollkommen zu! :thumb:

Und teilweise finde ich, geht die OOP-Programmierung sogar etwas zu weit. Wenn ich mal an Leute wie Robert denke, die jedes noch so kleine Array durch eine TList/TObjectList ersetzen wollen, und sich dabei nur unnötige Arbeit machen. Dabei find ich Arrays an sich gar nicht so schlimm, ganz im Gegenteil, finde ich sie sehr hilfreich, da sie schnell und einfach einsetzbar sind.

Zitat:

Zitat von DGL-luke

und vor allem macht OOP sehr viel mehr arbeit als prozedurale programmierung. zumindest meines Ermessens(kann auch daran liegen, dass bei mir OOP bis jetzt mit "Komponentenprogrammierung" äquivalent ist und ich da noch nicht ganz durchsteig).

Ich muss dir auch zustimmen. OOP macht einiges mehr an (Tipp-)Arbeit, was auf Dauer sehr lästig sein kann. Und bei Komponentenprogrammierung hat man ohne OOP schon keine Chance mehr, weil Komponenten prinzipiell OOP aufgebaut sind. Auch, wenn es manchmal ach so leicht ist, eine Klasse zu erstellen und alles was dazu passt in dieser Klasse auszulagern, macht so etwas manchmal einfach zu viel Arbeit (besonders für Leute wie mich, die keine Pro-Versionen besitze/nutze (D5 Pro steht zwar im Profil, aber die ist nicht so 100% legal (keine eigene Lizenz bei Schülerversion), deshalb benutz ich sie ungern). Die müssen nämlich alles einzeln machen :(

[Robert_G]

Und schon gates los... :roll:

[Sprint]

Zitat:

Zitat von malo

Auch, wenn es manchmal ach so leicht ist, eine Klasse zu erstellen und alles was dazu passt in dieser Klasse auszulagern, macht so etwas manchmal einfach zu viel Arbeit (besonders für Leute wie mich, die keine Pro-Versionen besitze/nutze

Das spielt doch gar keine Rolle, ob du 'ne Standard/Personal, Professional, CS/Enterprise oder 'ne Architect hast.

[Luckie]

Faulheit oder Bequemlichkeit ist für mich keine Ausrede nicht sauber zu programmieren, sei es jetzt OOP oder nicht.

[sniper_w]

Zitat:

Und schon gates los... Rolling Eyes

Also :mrgreen: .Tut mir leid für mein Posting (weil es OT ist), aber das war einfach lustig. MrGreen ist verdient.

[Robert_G]

Zitat:

Zitat von sniper_w

Zitat:

Und schon gates los... Rolling Eyes

Also :mrgreen: .Tut mir leid für mein Posting (weil es OT ist), aber das war einfach lustig. MrGreen ist verdient.

Normalerweise wäre da ein -> :mrgreen: <- gewesen.
Aber diese Milchmädchenrechungen und Rumpiekereien oder hach so tolerante, komplett jedem sinnvollen Inhalts, beraubte Aussagen wie wenigstens 2 der letzten paar Beiträgen, finde ich einfach zu nervig um darüber lachen zu können...

[DGL-luke]

gleich mal vorweg: ich will hier keinen flame anfangen... :?

Zitat:

Zitat von Robert_G

Warum sollte ich erklären, was ich meine. Du scheinst einfach nur nicht alles verstanden zu haben.
Und was ich mit dieser letzten Frage meinte, war eher dass Hagens (gewöhnlich) langer Beitrag IMHO fehl am Platz war, da das Thema gar nicht wirklich aufkam...

Was gibt es an einem einzigen Satz denn nicht zu verstehen, abgesehen davon, dass er zu wenig Information liefert? Oder meinst du, ich habe Hagens Text nicht verstanden? Das hat aber dann nichts mit dem, was du zitierst, zu tun.

Zitat:

Zitat:

ich würde hagen hier zustimmen: auch prozedurale programmierung kann sauber sein.

Was ist denn das für ein Argument? :gruebel:
a) Ging es hier überhaupt nicht darum und b) ist ein "X kann doch auch OK sein" in etwa so aussagekräftig wie auf alles mit 42 zu antworten. :roll:

Das ist kein Argument, ich wiederhole nur Hagens These, bevor ich weiter darauf bezug nehme.

Zitat:

Zitat:

Zitat von DGL-luke

und vor allem macht OOP sehr viel mehr arbeit als prozedurale programmierung.

Wieder so ein Ding, das hier absolut OT ist und schnell in einem Krieg angepupter Nicht-OOP'ler ausartet...

"angepupt" bist hier wohl eher du, nach deiner Reaktion zu schließen. Ich bin "Nicht OOP-ler", wenn man das so sagen kann.
Und zu OT: geht es hier nicht um saubere Programmierung bzw. das was man selbst dafür hält? Deine These "hier In diesem Thread geht es nicht um OOP" lässt mich vermuten, dass DU hagens Beitrag nicht wirklich verstanden hast.

Auch kann ich gerne nochmal ein paar Argumente liefern:

- mehr Tipparbeit (soltle unstrittig sein...)
- Mehr Denkarbeit (Erzeugen/Freigeben von Objekten die innerhalb der Klasse benutzt werden, Verpacken in eine Klassenstruktur, ...)

Zitat:

Zitat:

Zitat von DGL-luke

zumindest meines Ermessens(kann auch daran liegen, dass bei mir OOP bis jetzt mit "Komponentenprogrammierung" äquivalent ist und ich da noch nicht ganz durchsteig).

Was sagst du, wenn ich dir nun vorwerfe, dass du für fast keine deiner Aussagen eine Begründung geliefert hast?

wenn ich nur zwei aussagen mache, und davon eine begründe(wobei ich die begründung für die zweite ja oben nachreiche), muss ich wohl akzeptieren, dass du das für "fast keine" hältst.

Zitat:

Ehrlich gesagt interessiert es mich nicht wirklich. Es ging mir nur darum, dass du mir erst etwas vorwirfst, was du im selben Beitrag selbst machst... :gruebel:

Mich interessiert es auch nicht - worüber reden wir gleich noch mal? :zwinker:

Zitat:

btw: @Nico
Jupp, ich glaube das tun wir wohl alle... ;)

full ack.

Abschließend zu den inzwischen neuen Postings:

Zitat:

Und schon gates los... Rolling Eyes

wie bereits gesagt, ich will hier keinen flame anfangen.

Zitat:

Das spielt doch gar keine Rolle, ob du 'ne Standard/Personal, Professional, CS/Enterprise oder 'ne Architect hast.

Doch, mit einer Personal bist du echt am Darmausgang bei allem, was über Klickibunti(sprich implementierung von standardevents) hinausgeht.

PS: tut mir leid, ich muss jetzt senden, gleich ist meine internetzeit aus. vergebt mir also evtl. fehlendes debugging ;)

[TeronG]

Ich finde GloKale Variabeln (da/wenn sie zur übersicht beitragen) garnet mal so schlecht ... nur leider versteh ich den ersten Post (code) nicht wirklich ganz :gruebel:

was ich nur schade finde ist, daß solche Threats immer (oft) zu einer grundsatzdiskusion ausarten .. und das bei einem Thema wo es sowas garnicht geben sollte ... man muss doch immer seine Werkzeuge nach der Anforderung wählen und nicht nach Philosophie (Schraubendreher?? nix da! bin Hammer-fan!) ... naja egal ...

[edit's]bugfixing ... (ja alle edit's :oops: )

[malo]

Zitat:

Zitat von Sprint

Zitat:

Zitat von malo

Auch, wenn es manchmal ach so leicht ist, eine Klasse zu erstellen und alles was dazu passt in dieser Klasse auszulagern, macht so etwas manchmal einfach zu viel Arbeit (besonders für Leute wie mich, die keine Pro-Versionen besitze/nutze

Das spielt doch gar keine Rolle, ob du 'ne Standard/Personal, Professional, CS/Enterprise oder 'ne Architect hast.

Doch, wenn es um OOP-Programmierung geht. Methoden deklarieren etc, funktioniert in Pro/Ent/Arc-Versionen bedeutend einfacher und schneller, Stichwort: Code-Completion mit Strg+Shift+C. Dieses Feature wird in PE-versionen nicht unterstützt und erleichtert in Pro/Ent/Arc-Versionen die OOP-Programmierung bedeutend.

Zitat:

Zitat von Luckie

Faulheit oder Bequemlichkeit ist für mich keine Ausrede nicht sauber zu programmieren, sei es jetzt OOP oder nicht.

Das ist es auch nicht. Allerdings wollte ich damit ausdrücken, dass manches, was man mit der OOP macht, einfach overkill ist (besonders wenn man PE-Versionen benutzt), da man da einige Zeit an Tipparbeit verliert, die genausogut für wichtigere Dinge genutzt werden kann. Das ist imho einer der Nachteile an OOP."Sauber" Programmieren ist natürlich immer wichtig, aber der Weg dorthin spielt auch eine wichtige Rolle. Man kann sich stundenlang hinsetzen und ein ausgeklügeltes OOP-Konzept entwickeln, man kann aber auch procedural arbeiten und nur das in Klassen schreiben, was dort wirklich besser aufgehoben ist (zum Beispiel, wenn dabei Vererbung einem hilfreich zur Seite stehen könnte). Und solange man nachher noch durch das ganze durchsteigt, kann man imho arbeiten wie mal will/kann/es für richtig hält ;)

//edit: Sorry, wenn das hier auch OT ist... da hab ich beim posten nicht drauf geachtet :oops:

[Sprint]

Zitat:

Zitat von malo

Code-Completion mit Strg+Shift+C. Dieses Feature wird in PE-versionen nicht unterstützt und erleichtert in Pro/Ent/Arc-Versionen die OOP-Programmierung bedeutend.

Wenn du diese Funktion unbedingt brauchst, dann wäre jetzt vielleicht der Zeitpunkt dich mit der OpenTools API zu beschäftigen.

[nailor]

Zitat:

Zitat von Sprint

Zitat:

Zitat von malo

Code-Completion mit Strg+Shift+C. Dieses Feature wird in PE-versionen nicht unterstützt und erleichtert in Pro/Ent/Arc-Versionen die OOP-Programmierung bedeutend.

Wenn du diese Funktion unbedingt brauchst, dann wäre jetzt vielleicht der Zeitpunkt dich mit der OpenTools API zu beschäftigen.

oder sich eine Pro-Version zu kaufen.

[Hansa]

Zitat:

Zitat von Dax

Ums direkt zu sagen: Lokale Variablen mit Globaler Lebensdauer sind größtmöglicher Schwachsinn. Da kannst du auch gleich globale Variablen nehmen, was genauso schwachsinnig ist ;)

Das von dir Gesagte ist wirklich Schwachsinn ! Da gebe ich Dir Recht. :mrgreen: Was ist aber jetzt mit der Hauptfrage ? Ich halte die Sichtbarkeit von Variablen möglichst gering. Es gibt allerdings auch welche, die global sind, weil sie sich nicht ändern.

[negaH]

Geht es hier nun um die Frage was ein guter Programmierstil ist oder nicht ?

In meinen Postings wollte ich ganz klar ausdrücken das die Vermischung von Programmier-stil mit spezifischen Funktionalitäten diverser Programmiersprachen, sprich also OOP, rein garnichts zur Fragestellung beitragen kann.

Fängt man also an zu behaupten das die Anwendung von OOP ein guter Programmierstil sei, so vermischt man zwei komplett unterschiedliche Argumentationswelten. Das im Endeffekt die sprachliche Funktionalität der OOP in Delphi ein Indiz für einen guten Stil darstellt ist nur eine der vielen Konsequenzen eines guten Stiles an sich. Also nicht die Anwendung von OOP oder anderen Methoden definiert einen guten Stil sondern exakt umgekehrt. Zuerst war der Mensch mit seinen charakterlichen Zügen, dann kam die Machnine Computer (erfunden von Menschen) und erst dann die verschiedenen Programmiersprachen (erfunden von Menschen) die erst dann mit der Zeit unterschiedliche Methoden der Programmierungen einführten (also zb. OOP, erfunden von Menschen). Und erst nach diesen vielen zeitlichen Schritten konnte es Programmierer geben die nun behaupten das OOP der beste Stil überhaupt wäre (die sich über Erfindungen von Menschen streiten). Somit ist aus Sicht dieser Programmierer das Ei vor der Henne da gewesen.
Der einzigste Fixpunkt zur Beurteilung eines Programmierstils ist der Mensch an sich.

Nun was ich ausdrücken wollte ist das ein guter Programmierstil eher die Frage nach den Fähigkeiten eines Menschen ist als die Frage mit welchen Werkzeugen oder Methoden dieser Mensch seine Programme programmiert. Denn aus Sicht des Programmierstils sind die Werkzeuge und Methoden ohne zeitliche Dauer und Relevanz, denn sie werden sich mit der Zeit immer drastischer verändern. In 100 Jahren müsste man die OOP also als schlechten Stil betrachten da es dann ganz andere Werkzeuge geben wird. Aber, der Mensch der diese Werkzeuge benutzt wird sich denoch von anderen Menschen in seinen Fähigkeiten und Fertigkeiten unterscheiden. Und exakt diese Untrschiede zwischen den einzelnen Menschen in ihrer Art&Weise zu programmieren definiert dann einen unterschiedlichen Stil !

Programmieren ist also als Denkvorgang eines Menschens zu vestehen. Und je nachdem wie dieser Mensch ein Problem gedanklich anpackt, es zielstrebig zerdröselt und in Teilprobleme zerlegen kann, wie er dann die richtigen Werkzeuge auswählt, sich also entweder für oder gegen die Methode der OOP entscheidet, abhängig vom Problem, bestimmt den Stil !

Es wird niemals eine dauerhafte und unveränderliche Technologie existieren die uns die Grundlage für Behauptungen wie "OOP ist guter Stil" sachlich gegründbar darlegen kann.

Technologie = Werkzeug = Programmiersprache, Sprachfeatures, Programmiermethoden wie OOP, procedural etc. pp. Diese Technologie verändert sich ständig und wird durch Menschen weiter verändert.

Programmieren = das Denken eines Menschens

Programmier-Stil = die einmalige und individuelle Signatur des Denkens eines Menschens, also wie programmiert, bzw. denkt ein Mensch.

Betrachtet man das mal aus dieser Sichtweise so erscheinen viele Aussagen in diesem Thread einfach lächerlich. Eben weil man die heutige Technologie nicht als Indiz zur Beweisführung eines guten Programmierstils heranziehen darf.

Gruß Hagen

[negaH]

Und nun konkret zur Eingangsfrage:

Ja, wenn es eine sinnvolle Verwendung für stark lokal begrenzt sichtbare aber global wirkende Variablen gibt dann sollte man mit solchen Restriktionen unbedingter Weise auch arbeiten.

Es ist also nicht egal ob man eine solche Variable ganz global definiert wenn es nicht unbedingt sein müsste. Einen durchdachten Programmierstil würde man nun daran erkennen das der Programmierer die Sichtbarkeit dieser Variable auf das notwendigste Maß beschänkt. Und wie in der Eingangsfrage als Beipspiel aufgezeigt kann man so die Sichtbarkeit dieser Variablen auf eine einzigste lokale Funktion beschränken, weil die Variable eben nur dort nötig ist. Das ist in fact ein guter Stil, ganz unabhängig von OOP, proceduraler Programmierung oder das dieses Feature durch Borland in Zukunft wegretionalisiert wird. Wer sagt denn das die Borländer die Superschlauberger sind und die Entfernung dieses Features in Zukunft wirklich ein sinnvoller Schritt darstellt ? Ich persönlich habe mich bei der Umstellung von D5 auf D7 ziemlich gewundert das Borland diesen Schritt vollzogen hat.

Gruß Hagen