SingleTon Klasse

[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

[oop]

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?

[oop]

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

[otze]

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.

hab ich auch nie behaupted. ich sagte dem sinn nach eher was von "T existiert nur einmal"

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

das stimmt, aber normalerweise haben variablen ja auch eine größe, einen int hat(um flames vorzubeugen:normalerweise) 32 bits, der speiechrbereich der variablen im speicher ist 32 bits groß.

meine klasse hat o bits als platz für sich beansprucht. wird im speicher nun ein 0 bit großer speicehrbereich angelegt,oder mehr? Oder ist der compiler schlau genug, um zu merken, dass er sich hier nicht diese arbeit machen muss?

[virtuell Realisticer]

otze schrieb:

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.

hab ich auch nie behaupted. ich sagte dem sinn nach eher was von "T existiert nur einmal"

Beim Singleton redet man von Instanz der Klasse, nicht von Instanz der Member.

otze schrieb:

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

das stimmt, aber normalerweise haben variablen ja auch eine größe, einen int hat(um flames vorzubeugen:normalerweise) 32 bits, der speiechrbereich der variablen im speicher ist 32 bits groß.

meine klasse hat o bits als platz für sich beansprucht. wird im speicher nun ein 0 bit großer speicehrbereich angelegt,oder mehr? Oder ist der compiler schlau genug, um zu merken, dass er sich hier nicht diese arbeit machen muss?

Ich meine mich an einen Thread hier erinnern zu koennen, wo jemand das
angesprochen hatte. Ich denke der Compiler wird hier mindestens 1 Byte Speicher
reservieren, welcher das Objekt repraesentiert. Schlau wird der Compiler wohl
auf jeden Fall sein. Ob es dazu etwas im Standard gibt weiss ich nicht, aber
ich werde mal den Draft durchsuchen.

mfg
v R

[DEvent]

net schrieb:

DEvent schrieb:

...
        static void createSingelton(/*Paramter die zum erstellen gut sind*/)
        { singelton = new Singelton(/*Paramter die zum erstellen gut sind*/);
        }
...

musst aber noch verhindern, dass 'createSingleton' mehrfach aufgerufen wird. sonst hat man doch mehrere instanzen

wieso das? ein programmierer sollte schon wissen was er macht ...
die regel ist doch ganz einfach: rufe in deiner main funktion einmal createSingelton() auf und am ende dann deleteSingelton. viele APIs haben auch solche einfache regel, wenn man sich nicht drann hält selbst schuld. ( z.b. winapi mit getDC() releaseDC(), oder D3DX mit BeginScene() EndScene() )
aber man könnte ja auch machen

void createSingelton()
{
    if ( sengelton ) return;
    singelton = new Singelton();
}

natürlich kann man an der implementierung von singelton rumtricksen aber das prinzip bleibt das gleiche

[oop]

@virtuell Realisticer:
dann brauch ich in der klasse kein

~Client();

hab ich das richtig verstanden?

cu