Singleton Pattern

[blurry333]

#include <iostream>

  class Singleton
  {
    private:
      //Konstruktor private, damit man sich keine Instanzen holen kann.
		Singleton(){}
      //Den Kopierkonstruktor schützen um zu vermeiden, dass das Objekt unbeabsichtigt kopiert wird.
		Singleton(const Singleton& cc){}

    public:
		~Singleton(){}
	  static Singleton& getInstance();
  };

  Singleton& Singleton::getInstance()
  {
    Singleton instance;
    return instance;
  }

void main(void){

	Singleton& x=Singleton::getInstance(); // REferenz auf lokales Objekt

}

ich hab in der methode getinstance() das static weggelassen . trotzdem funktionierts. Jetzt könnten wohl auch mehrere Instanzen von singleton angelegt werden. Frag mich trotzdem welche Referenz getinstance da zurückliefert.
die instance variable ist ja jetzt lokal .

[volkard]

Das crasht. Nix gut.

[Gast]

blurry333 schrieb:

Singleton& Singleton::getInstance()
  {
    Singleton instance;
    return instance;
  }

Hier sollte dein Compiler eine Warnung ausgeben, weil du eine Referenz auf
ein Stack-Objekt zurücklieferst.

blurry333 schrieb:

ich hab in der methode getinstance() das static weggelassen . trotzdem funktionierts. Jetzt könnten wohl auch mehrere Instanzen von singleton angelegt werden. Frag mich trotzdem welche Referenz getinstance da zurückliefert.
die instance variable ist ja jetzt lokal .

Bei jedem Aufruf der Funktion wird ein neues Objekt auf dem Stack angelegt.
Warum es nicht crashed?
You're lucky.
Im Stack steht zwar noch der Inhalt aber das Objekt existiert nicht mehr.
Wenn du den Stack nun beanspruchst (Funktionsaufrufe oder lokale Variablen)
wirst du die Werte überschreiben. Spätestens dann crashed es!

[unskilled]

das kompiliert nicht mal:
void main(void){

bb

[knivil]

trotzdem funktionierts.

Undefiniertes Verhalten, manchmal funktioniert es.

[blurry333]

static Variablen einer Funktion werden wohl im ARbeitsspeicher und nicht
auf dem STack abgelegt ?

[Michael E.]

Zwar ist deine Aussage streng genommen korrekt, aber sicher nicht das, was du meinst. Der Stack liegt auf dem Arbeitsspeicher. Der Arbeitsspeicher wird für dich als Anwendung aufgeteilt in unterschiedliche Bereiche (nicht physikalisch gesehen, sondern logisch) und einen solchen Bereich nennt man Stack.

Edit: Wobei Arbeitsspeicher wieder etwas zu ungenau formuliert ist. Mit Arbeitsspeicher meine ich hier deinen Hauptspeicher (RAM) und alle möglichen Caches.

[Gast]

blurry333 schrieb:

static Variablen einer Funktion werden wohl im ARbeitsspeicher und nicht
auf dem STack abgelegt ?

Der Arbeitsspeicher unterteilt sich in mehrere Bereiche.
Mir fallen gerade mal ein: Stack, Heap, Programmcode (kein Plan wie der Fachmännisch heißt)
Der Stack ist wie der Name schon sagt ein Stapel.
Dort wird alles an lokalen Variablen, Funktionsparametern, Rücksprungadressen für Funktionen
abgelegt. Wenn der Gültigkeitsbereich einer Variablen oder Funktionsparameter
vorüber ist oder die Funktion beendet ist, wird der Bereich wieder verwendet.
Wenn du Daten auf dem Heap anlegen möchtest mußt du diese mit new, new[] (oder
malloc) erzeugen. Dann organisiert dir dein Betriebssystem irgendwo einen
Speicherbereich den du verwenden kannst. Nachteil: Du mußt diesen manuell
wieder freigeben (delete, delete[] oder free)
Dann gibts noch einen anderen Bereich, wo der Programmcode ist.
Dieser ist eigentlich weniger von Bedeutung, allerdings vermute ich
dass statische Variablen dort verankert werden. Ich weiß es aber nicht!!!

Gruß,
CSpille

[SeppJ]

CSpille schrieb:

Dann gibts noch einen anderen Bereich, wo der Programmcode ist.
Dieser ist eigentlich weniger von Bedeutung, allerdings vermute ich
dass statische Variablen dort verankert werden. Ich weiß es aber nicht!!!

Halbkorrekt. Es gibt einen Bereich der sich Data nennt, da werden statische und globale Variablen gespeichert. Auch die Literale liegen hier. Dann gibt es noch das Codesegment, wo der eigentliche Programmcode liegt. Dies ist aber von den statischen Variablen abgegrenzt und (sofern die Architektur dies erlaubt) gegen Schreiben geschützt.

Man sollte aber noch sagen, dass diese ganze Unterteilung alles nur Konvention ist, wie Compiler ihren Code organisieren. Die Prozessoren und Betriebssysteme kommen ihnen mit Spezialfunktionen entgegen, weswegen es auch Sinn macht, sich daran zu halten. Aber wenn man beispielsweise selber ein Programm in Assembler schreibt, dann braucht man sich überhaupt nicht darum zu kümmern (Es macht aber Sinn, es trotzdem zu tun, die Einteilung ist schon gut überlegt). Oder wenn man seinen eigenen Compiler schreibt, braucht der Code den dieser Erzeugt sich auch nicht daran zu halten. Natürlich wäre Kompatibilität mit anderen Compilern dadurch vollständig ausgeschlossen.

[Gast]

SeppJ schrieb:

CSpille schrieb:

Dann gibts noch einen anderen Bereich, wo der Programmcode ist.
Dieser ist eigentlich weniger von Bedeutung, allerdings vermute ich
dass statische Variablen dort verankert werden. Ich weiß es aber nicht!!!

Halbkorrekt. Es gibt einen Bereich der sich Data nennt, da werden statische und globale Variablen gespeichert. Auch die Literale liegen hier. Dann gibt es noch das Codesegment, wo der eigentliche Programmcode liegt. Dies ist aber von den statischen Variablen abgegrenzt und (sofern die Architektur dies erlaubt) gegen Schreiben geschützt.

Ich erinner mich...
Lang ist es her...
Assembler cs und ds
bzw. .code und .data