|
You last visited: Today at 05:00
Advertisement
Singletons
Discussion on Singletons within the C/C++ forum part of the Coders Den category.
05/27/2013, 16:39
|
#31
|
elite*gold: 0
Join Date: Dec 2012
Posts: 255
Received Thanks: 110
|
Quote:
Originally Posted by MrSm!th
Du meinst...du speicherst einfach alle dynamischen Objekte in ner Sammelsingleton?
|
Nope, naja nicht in einem einzigen Singleton.
|
|
|
05/27/2013, 20:04
|
#32
|
elite*gold: 7110
Join Date: Jun 2009
Posts: 28,904
Received Thanks: 25,394
|
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 :/
|
|
|
05/27/2013, 22:14
|
#33
|
elite*gold: 0
Join Date: Dec 2012
Posts: 255
Received Thanks: 110
|
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 :/
|
Ich weiß ja nicht wo du schaust, aber bei mir ist der Singleton Konstruktor protected. Durch die Vererbung wird versichert, dass die Singleton Klasse maximal einmal existiert, sonst gibts ne Ausnahme.
Elegant ist es schon meiner Meinung nach, ich wüsste zumindest keinen besseren Weg.
Würde ich hier ein zweites Objekt der Klasse D3DManager erzeugen, dann gäbs halt ne Ausnahme.
Und nun soll mir jemand erklären, wie er seine Anwendung initialisiert und Referenzen zu dynamischen Objekten hält, ohne ein Singleton.
|
|
|
05/28/2013, 13:11
|
#34
|
elite*gold: 7110
Join Date: Jun 2009
Posts: 28,904
Received Thanks: 25,394
|
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
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 Das wäre doch nicht weniger dynamisch ohne Singleton.
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.
|
Ich habe echt 0 Ahnung, was du mit deinen Referenzen hast. Wieso sollte dafür eine Singleton notwendig sein?
|
|
|
05/28/2013, 13:50
|
#35
|
elite*gold: 0
Join Date: Dec 2012
Posts: 255
Received Thanks: 110
|
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
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 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?
|
Du hast da also eine Anwendung ohne einen Manager? Das ist ja echt seltsam, sowas ist mir noch nie untergekommen... 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. Dynamisch ist das deswegen, da ich bei Anwendungsstart mit den smart pointern prüfen kann, ob ich hier z.B. den D3DManager von DirectX9 brauche oder den 11er. "Interface"-Singletons werden dann möglich.
Ich glaube deine Singleton Vorstellung sieht so aus:
Code:
#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>
Code:
class SomeSingleton : public Utils::Singleton<SomeSingleton>
{
SINGLETON_OBJ(SomeSingleton);
SomeSingleton() {}
public:
void DoSomething();
}
#define sSingleton ::Utils::Singleton<::SomeSingleton>::Instance()
Das ist natürlich auch möglich, allerdings sind hier Interface Singletons unmöglich.
|
|
|
05/29/2013, 00:18
|
#36
|
elite*gold: 7110
Join Date: Jun 2009
Posts: 28,904
Received Thanks: 25,394
|
Quote:
Du hast da also eine Anwendung ohne einen Manager?
|
Jup.
Wir reden vermutlich aneinander vorbei.
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.
|
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).
|
|
|
05/29/2013, 01:15
|
#37
|
elite*gold: 0
Join Date: Dec 2012
Posts: 255
Received Thanks: 110
|
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).
|
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.
Es gibt einfach genug Fälle in denen man Klassen benutzt, die einfach nur einmal Sinn machen. Mehrere Objekte sind da einfach schwachsinnig, und alles das wird bei mir als Singleton definiert.
Ich meide außer die Singletons jede Art von globalen Objekten, aber bei Singletons bin ich der Auffassung, das man ohne sie nicht auskommt. Sie machen einfach Sinn und sind dort wo sie Sinn machen einfach die bestmöglichste Lösung.
|
|
|
05/29/2013, 01:22
|
#38
|
elite*gold: 7110
Join Date: Jun 2009
Posts: 28,904
Received Thanks: 25,394
|
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.
|
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
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.
|
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.
|
|
|
05/29/2013, 01:26
|
#39
|
elite*gold: 0
Join Date: Dec 2012
Posts: 255
Received Thanks: 110
|
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.
|
Das ist richtig ja, ich rede auch von nichts anderem. Da meine Anwendungen sowieso ausschließlich aus Klassen bestehen macht einfach mal mindestens ein Singleton Sinn in dem man mal Daten über die Anwendung selber ablegt und seine Initialisierungsmethoden da drin definiert. Der Rest bleibt dann aber völlig flexibel und da wird dann nur zu statischen oder globalen Variablen gegriffen wenn wirklich notwendig.
Um nochmal auf mein spezielles Design der Singletons einzugehen: Der smart pointer erlaubt mir Singletons zu benutzen, die erst zur Laufzeit erstellt werden.
Damit kann ich dann per Interfaceklasse die richtigen Singleton Instanzen auswählen.
|
|
|
All times are GMT +2. The time now is 05:00.
|
|