Singletons

Quote:

Originally Posted by MrSm!th Du meinst...du speicherst einfach alle dynamischen Objekte in ner Sammelsingleton?

Quote:

Originally Posted by MrSm!th Eine seltsame Singleton-Definition, bei der der Konstruktior nicht private ist ;O Verstehe jetzt aber nicht recht, wo da nun der Unterschied zu den bereits genannten Anwendungsgebieten und die Eleganz ist, kann aber auch daran liegen, dass ich gerade auf der Leitung stehe :/

Quote:

Originally Posted by Master674b Und nun soll mir jemand erklären, wie er seine Anwendung initialisiert und Referenzen zu dynamischen Objekten hält, ohne ein Singleton.

Quote:

Originally Posted by MrSm!th Wie kannst du dann ein globales Objekt der Klasse erstellen? Da müsste dann doch der Compiler meckern. Ich kenne Singletons mit einer statischen instance() Methode, die das Objekt liefert ;O Da gibt's keine Ausnahme, da kann man einfach nicht mehr als ein Objekt haben. Finde auch irgendwie das Design mit dem shared_ptr ungewöhnlich :o Naja wie schon gesagt wurde: Solche Fälle funktionieren auch gut ohne, sind aber wohl noch am ehesten für eine Singleton geeignet, da ja so ein Manager idr nur einmal Sinn macht. Wo da jetzt die Eleganz was Dynamik angeht ist, kapier ich immer noch nicht :D Das wäre doch nicht weniger dynamisch ohne Singleton. Ich habe echt 0 Ahnung, was du mit deinen Referenzen hast. Wieso sollte dafür eine Singleton notwendig sein?

#pragma once

namespace Utils
{
	template <class T>
	class Singleton
	{
	public:
		static T& Instance() {
			static T sInstance;
			return sInstance;
		}

	protected:
		Singleton() {}

	private:
		Singleton(const Singleton<T>&);
		Singleton<T>& operator=(const Singleton<T>&);
	};
}

#define SINGLETON_OBJ(T) friend class ::Utils::Singleton<T>

class SomeSingleton : public Utils::Singleton<SomeSingleton>
{
	SINGLETON_OBJ(SomeSingleton);
	SomeSingleton() {}

public:
	void DoSomething();
}

#define sSingleton ::Utils::Singleton<::SomeSingleton>::Instance()

Quote:

Du hast da also eine Anwendung ohne einen Manager?

Quote:

Irgendwo hast du doch mindestens mal ne Log Klasse. Und da gehts dann los, sowas zählt bei mir schon als Singleton, ob das nun abgesichert ist dass man es nur einmal erstellen kann oder nicht.

Quote:

Originally Posted by MrSm!th Jup. Wir reden vermutlich aneinander vorbei. Wie man in den verlinkten Quellen auch nachlesen kann: Nö. Zwischen "Es gibt nur ein Objekt" und "Es darf nur ein Objekt bestehen" gibt es einen Unterschied. Es kann durchaus Sinn machen, mehrere Logger zu haben, auch wenn man im Programm gerade vielleicht nur einen nutzt. Es gibt eigentlich nichtmal all zu viele Fälle, bei denen tatsächlich jetzt und für alle Zeit nur ein Objekt vorhanden sein darf, wenn man mal von technischen Gegebenheiten absieht (schon klar, wenn eine Hardware-Schnittstelle oder irgendeine Lib, die gekapselt wird, nur ein Objekt erlaubt, dann geht es halt nicht anders).

Quote:

Würde man es so betrachten: Nein man braucht keine Singletons, da man einfach eine globale Instanz erzeugen kann und fertig, ohne Sicherungen ob es mehrfach erstellt wird oder nicht.

Quote:

Ich meide außer die Singletons jede Art von globalen Objekten, aber bei Singletons bin ich der Auffassung, das man ohne sie nicht auskommt.

Quote:

Originally Posted by MrSm!th So war es nicht gemeint, nein. Das hätte denselben Nachteil in Sachen Wartbarkeit. Wenn es tatsächlich nur ein Objekt gegen darf, ist eine Singleton ja ok. Aber wenn nicht, dann halt nicht. Dann ist ein globales Objekt auch nicht besser, warum so viel Sichtbarkeit? ;O Hm, doch. Es gibt durchaus mal Fälle, wo es nicht anders geht, schon richtig. Dann sind sie natürlich auch angebracht. Aber das ist nicht anders als bei globalen Objekten - man nutzt sie eben nur, wenn es wirklich notwendig ist und in den allermeisten Fällen kommt man super ohne aus.