SingleTon Klasse

interpreter

Shlo schrieb:

Ich verstehe nicht warum ihr für eine einzige Instanz eine ganze Klasse braucht:
template<class T>
T& my_instance()
{
    T a;
    return a;
}
reicht vollkommen.

Das hat nichts mit Singleton zu tun, da hier überhaupt keine Begrenzung der Anzahl an Instanzen durchgeführt wird.
Nebenbei: Eine Referenz auf ein lokales Objekt?

Shlo

interpreter schrieb:

Nein. Natürlich nicht. Das Single soll verdeutlichen, dass es mehrere Instanzen geben kann! Man kanns sichs auch zurechtformen, wie mans braucht...
Schau bitte noch mal nach, was genau singleton bedeutet.

Und wieder ein gescheiterter Versuch, sich auf einer äußerst dämlichen Weise, zu rechtfertigen... Aber was solls, mit der Wand zu reden würde mehr Sinn machen, als mit dir. Ich gebe auf...

Shlo

SideWinder schrieb:

@Shlo: Ganz sicher, dass du den Sinn von Singletons verstanden hast? Nicht eine erstellen, sondern *maximal* eine erstellen.

Zu schnell getippt, static müsste da stehen.

interpreter

Shlo schrieb:

interpreter schrieb:

Nein. Natürlich nicht. Das Single soll verdeutlichen, dass es mehrere Instanzen geben kann! Man kanns sichs auch zurechtformen, wie mans braucht...
Schau bitte noch mal nach, was genau singleton bedeutet.

Und wieder ein gescheiterter Versuch, sich auf einer äußerst dämlichen Weise, zu rechtfertigen... Aber was solls, mit der Wand zu reden würde mehr Sinn machen, als mit dir. Ich gebe auf...

Diese Masche scheinst du immer zu bringen, wenn du nicht mehr weiter weißt.
Zu meiner Aussage: Du weißt was Ironie ist?

Shlo

interpreter schrieb:

Zu meiner Aussage: Du weißt was Ironie ist?

Ah, das nennst du so, genau so wie mit deiner Rhetorik... Alles klar. lol

interpreter

Shlo schrieb:

interpreter schrieb:

Zu meiner Aussage: Du weißt was Ironie ist?

Ah, das nennst du so, genau so wie mit deiner Rhetorik... Alles klar. lol

Ich schreibs am besten jetzt immer dazu

Shlo

interpreter schrieb:

Ich schreibs am besten jetzt immer dazu

Ja, müsste ich auch. (das war keine)

interpreter

Schon witzig, dass es immer Streit gibt wenn du dazu stößt. Is bestimmt nur Zufall...

Shlo

SideWinder schrieb:

T& obj = my_instance<T>();
T obj2; // ohje

Mit bereits geposteten Vorschlägen würde das auch nicht anders gehen. Man könnte aber den ctor der Klasse private machen und my_instance als friend deklarieren.

SideWinder

Kommt mir vor als hätte ich das bereits geschrieben.

MfG SideWinder

otze

imho bietet _jeder_ generische singleton die bereits genannten nachteile, an dem punkt muss man wohl die verantwortung in die hand des programmierers geben.

virtuell Realisticer

Eure Diskussion ist voellig unnoetig. Wenn einer meint die Definition eines
Singleton zu aendern, dann soll er das tun.

In einem bereits geposteten Link beschreibt Hume exakt, was ein Singleton
ausmacht und ich kann es auch gerne nochmal aus Modern C++ Design zitieren:

...
Singleton's description in the GoF book is as simple as it gets: "Ensure a class
only has one instance, and provide a global point of access to it."

A singleton is an improved global variable. The improvement that Singleton
brings is that you cannot create a secondary object of the singleton's type.
Therefore, you should use Singleton when you model types that conceptually have
a unique instance in the application, such as Keyboard, Display, PrintManager,
and SystemClock. Being able to instantiate these types more than once is
unnatural at best, and often dangerous.
...

mfg
v R

Shlo

SideWinder schrieb:

Kommt mir vor als hätte ich das bereits geschrieben.

Und?

SideWinder

Das was vorher da stand war viel netter Shlo.

MfG SideWinder

Objektinstanz dynamisch auf dem Heap anlegen:

class Client 
{ 
   private: 
     // Standard- und Copykonstruktor sind private. 
     // Nur Methoden dieser Klasse können auf sie zugreifen.
     Client() {}
     Client( const Client& );

     // Dekonstruktor
     ~Client(); 

     // Ein Zeiger auf die einzige Instanz
     static Client *m_instanz;

   public: 
     // Diese statische Methode erzeugt die einzige Instanz.
     // Nur über diese Methode erhalten Anwender den Zugriff auf
     // die Instanz.
     static Client* getInstance();

     static void deleteClient() { delete m_instanz; };  
}; 

Client* Client::m_instanz = 0; 

Client* Client::getInstance() 
{ 
  // Die Instanz wird erst beim ersten Aufruf erzeugt.
  if( m_instanz == 0 ) 
      m_instanz = new Client(); 
  return m_instanz; 
}

static void Client::deleteClient();

Objektinstanz statisch anlegen:

class Client
{
   // Standard- und Copykonstruktor sind private. 
   // Nur Methoden dieser Klasse können auf sie zugreifen.
   private:
     Client() {}
     Client( const Client& );

   public:
     // Diese statische Methode erzeugt die einzige Instanz.
     // Nur über diese Methode erhalten Anwender den Zugriff auf
     // die Instanz.
     static Client& getInstance();
};

Client& Client::getInstance()
{
  // Die Instanz wird erst beim ersten Aufruf erzeugt.
  // Endet das Programm, wird Instanz vernichtet.
  static Client m_instanz;
  return m_instanz;
}

wenn ich eine Objektinstanz dynamisch auf dem Heap anlege (siehe bsp 1) dann muss der benutzer das delete selber aufrufen? was hat der dekonstruktor dann zu tun?
beispiel 2 müsste so ok sein?

cu

Shlo

SideWinder schrieb:

Das was vorher da stand war viel netter Shlo.

Ja, fand ich auch

otze

Ensure a class
only has one instance, and provide a global point of access to it...

Therefore, you should use Singleton when you model types that conceptually have a unique instance in the application, such as Keyboard, Display, PrintManager, and SystemClock. Being able to instantiate these types more than once is unnatural at best, and often dangerous

diese beiden textstellen ließen eigentlich auch meine klasse als singleton zu.

sie sagen eigentlich nur, dass ein singleton alles ist was verhindert, dass von einer Klasse 2 instanzen existieren. mein singleton ließe auch nur eine instanz des "SystemClock" objekts zu.

Den globaln Accesspoint stellt dann die Klasse Singleton selber über den ctor und dem operator ->. Imho wird es wohl auch praktisch keinen unterschied machen, wenn man einen ctor anstatt einen statischen instance aufzurufen(bei inlinecode wird der compiler in beiden fällen hoffentlich das gleiche draus machen).

und selbst wenn ihr mir klar machen würdet, dass mein beispiel kein singleton darstellt, aus dem einen grund,dass der rumpf mehrfach existieren kann, so würde ich den ansatz weiterverfolgen, da er einige probleme die singletons haben einfach nicht hat :). nur würde ich mich fragen, was das effektiv ist, was ich mir da zusammengeschustert hab

ps: nur weil mich das mal aus compiler verstehtechnischen gründen in dem zusammenhang interessiert: verbraucht eine instanz einer klasse ohne nicht statischen variablen platz im speicher?

kann jemand meine frage auf page 5 letzter post beantworten?

cu

virtuell Realisticer

sie sagen eigentlich nur, dass ein singleton alles ist was verhindert, dass von
einer Klasse 2 instanzen existieren. mein singleton ließe auch nur eine instanz
des "SystemClock" objekts zu.

Code von interpreter:

Singleton<int> s1, s2, s3, s4;

Das sind fuer mich 4 Instanzen dieser Klasse. Du verhinderst, dass mehrmals
Speicher fuer objectPointer reserviert wird, aber du verhinderst ganz und gar
nicht, dass ich mehrere Instanzen deiner Klasse Singleton<T> erstellt
werden kann.

ps: nur weil mich das mal aus compiler verstehtechnischen gründen in dem zusammenhang interessiert: verbraucht eine instanz einer klasse ohne nicht statischen variablen platz im speicher?

Ich wuerde sagen schon. Wie andere Variablen, besitzt auch eine Instanz einer
Klasse einen Speicherbereich.

mfg
v R

virtuell Realisticer

was hat der dekonstruktor dann zu tun?

Der DTor bei der ersten Variante waere noetig, falls du irgendwelche Member hast,
die dynamisch erstellt worden sind.

beispiel 2 müsste so ok sein?

Ja ist es.

mfg
v R