lokale Variablen mit globaler Lebensdauer?

[NicoDE]

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 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 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 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?

[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 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 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 .

[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?
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.

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?

Oh und bevor jetzt jemand aufschreit dass es in managed C++ geht: Bitte vorher den IL Code ansehen.
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.