class MainClass
{
public:
	MainClass();
	~MainClass();
	void LoadSettings();
protected:
	static bool bsetting;
	static int  isettingvalue;
	//...
};

MainClass::MainClass()
{
}

MainClass::~MainClass()
{
}

void MainClass::LoadSettings()
{
	//Settings laden 
	//<-- Code hier -->

	bsetting = true;
}

int main()
{
	MainClass mClass;
	mClass.LoadSettings();
	return 0;
}

TestProject.obj : error LNK2001: unresolved external symbol "protected: static bool MainClass::bsetting" (?bsetting@MainClass@@1_NA)
1>TestProject.exe : fatal error LNK1120: 1 unresolved externals

Wie kann ich den Variablen denn nun einen Wert zuweisen? Natürlich könnte ich sich public machen und das dann außerhalb der Funktion machen, aber dann kann ich auch die globalen Variablen behalten.

tip:

static_variablen_typ meineklasse::static_variable;
außerhalb der klasse

und leeren Ctor und Dtor brauchste auch nich selbst implementieren, das macht der compiler schon für dich

bb

#include "stdafx.h"
#include "TestProject.h"

class MainClass
{
public:
	MainClass();
	~MainClass();
	void LoadSettings();
protected:
	static bool bsetting;
	static int  isettingvalue;
	//...
};

MainClass::MainClass()
{
}

MainClass::~MainClass()
{
}

bool MainClass::bsetting = true;

void MainClass::LoadSettings()
{
	bsetting = false;
}

int main()
{
	MainClass mClass;
	mClass.LoadSettings();
	return 0;
}

int main()
{
    MainClass mClass;
    mClass.LoadSettings();

    MainClass mClass2;
    mClass2.LoadSettings();    

return 0;
}

Macht nicht viel Sinn, da nur eine Instanz der Klasse MainClass Sinn macht, oder? - Dann ist das schon ein Fall für ein Singleton. Oder mach wenigstens auch die Funktionen der Klasse statisch und den Konstruktor privat. Dann hast du einen ähnlichen Effekt.

class Settings
{
private:
	//Ein Pointer zum Speichern der Instanz
	static Settings* instance;
    //Konstruktor private, damit man sich keine Instanzen holen kann.
	Settings(std::string FileName)
	{
		m_FileName = FileName;
	}
	std::string m_FileName;
    //Den Kopierkonstruktor schützen um zu vermeiden, dass das Objekt unbeabsichtigt kopiert wird.
	Settings(const Settings& cc){}
	~Settings(){}
public:
	static Settings* getInstance(std::string FileName);
    static void Destroy();
	void LoadSettings();

	bool bsetting;
	int isettingvalue;
};
Settings* Settings::instance = NULL;

Settings* Settings::getInstance(std::string FileName)
{
	if( !instance )
      instance = new Settings(FileName);
    return instance;
}

void Settings::Destroy()
{
	// static
    if (instance){
      delete instance;
      instance = NULL;
    }
}

void Settings::LoadSettings()
{
	//Code zum Laden der Settings
	// -------------------------
	bsetting = true;
	isettingvalue = 5;
}

class MainClass : public Settings
{
public:
    MainClass();
    ~MainClass();
	void TestMainClass();
    //...
};

void MainClass::TestMainClass()
{
	std::cout << "settingvalue from maincalss = " << isettingvalue;
	std::cin.get();
}

int main()
{
	Settings *settings = Settings::getInstance("mysettings.ini");
	settings->LoadSettings();

	//Ausgabe: 5 (ohne MainClass getestet)
	std::cout << "settingvalue = " << settings->isettingvalue;
	std::cin.get();

	MainClass mClass;
	mClass.TestMainClass();

    // Destroy instances
    Settings::Destroy();

	return 0;
}

1>TestProject.obj : error LNK2019: unresolved external symbol "public: __thiscall MainClass::~MainClass(void)" (??1MainClass@@QAE@XZ) referenced in function _main
1>TestProject.obj : error LNK2019: unresolved external symbol "public: __thiscall MainClass::MainClass(void)" (??0MainClass@@QAE@XZ) referenced in function _main
1>C:\Users\Wraithin\Documents\Visual Studio 2008\Projects\TestProject\Debug\TestProject.exe : fatal error LNK1120: 2 unresolved externals

Wahrscheinlich geht das so wieder nicht, wie ich es mir gedacht habe... Ich habe noch nie etwas mit Singleton Klassen gemacht und deshalb wäre es nett, wenn mir mal kurz jemand helfen könnte.

Hier nochmal der Code:

class Settings
{
private:
	//Ein Pointer zum Speichern der Instanz
	static Settings* instance;
    //Konstruktor private, damit man sich keine Instanzen holen kann.
	Settings()
	{
		isettingvalue = 12;
	}
    //Den Kopierkonstruktor schützen um zu vermeiden, dass das Objekt unbeabsichtigt kopiert wird.
	Settings(const Settings& cc){}
	~Settings(){}
public:
	static Settings* getInstance();
    static void Destroy();
	void LoadSettings(std::string FileName);

	bool bsetting;
	int isettingvalue;
};
Settings* Settings::instance = NULL;

Settings* Settings::getInstance()
{
	if( !instance )
      instance = new Settings();
    return instance;
}

void Settings::Destroy()
{
    if (instance)
	{
      delete instance;
      instance = NULL;
    }
}

void Settings::LoadSettings(std::string FileName)
{
	//Code zum Laden der Settings
	// -------------------------
	bsetting = true;
	isettingvalue = 5;
}

int main()
{
	Settings *settings = Settings::getInstance();
	std::cout << "settingvalue before LoadSettings = " << settings->isettingvalue << std::endl; // Output 12
	settings->LoadSettings("testfile.ini");

	std::cout << "settingvalue = " << settings->isettingvalue << std::endl; // Output 5
	settings->isettingvalue = 2;
	std::cout << "settingvalue = " << settings->isettingvalue; //Output: 2
	std::cin.get();

    Settings::Destroy();

	return 0;
}

Ich finde einfach das hier unnötig und "gefährlich".

Settings::Destroy();

Ich sehe den wirklichen Unterschied dieses Guards nicht wirklich zu Meyers. Läuft ja auf das gleiche hinaus. Wenn allerdings der Guard noch zusätzliche Funkitionalität, wie z.B eine manuelle Zerstörung anbietet, dann ist das etwas völlig anderes. Aber, wie gesagt braucht man das ja eher selten und das Meyers Singleton reicht völlig.

Oft ist es ideal wenn man Singletons garnicht zerstört.

Noch öfters ist es ideal, wenn man Singletons garnicht benutzt.

Oft ist es ideal wenn man Singletons garnicht zerstört.

Wenn nur eines vorhanden ist, dann ist es imo weniger tragisch. Dann zerstört es sich einfach als letztes. Sobald man aber Krieg der Singletons bestreiten will, dann wirds problematisch, wer sich selbst zerstört und wer auf den Leichen rumtrampelt..

Noch öfters ist es ideal, wenn man Singletons garnicht benutzt.

Vor allem nicht als Alternative zu globalen Variablen.

Was ist wenn man das Löschen, so wie hier beschrieben:http://www.oop-trainer.de/Themen/Singleton.html, mit einer guard-Klasse macht?

Dann hat man den Fall nicht zuende gedacht.
Warum hat der Wächter nur das Löschen und nicht auch noch das Erzeugen?
In Listing5 fällt die Asymmetrie stark auf.
Hauen wir das Erzeugen doch mal auch in den Wächter-Konstruktor und beobachten, was geschieht.
Es erinnert an was bekanntes. Moment, gleich kommts.
Den instanz-Zeiger und exemplar() auch in den Wächter rein!
Ja, wir habens raus. Es ist ein Meyers-Singleton, der ein gepimpltes Monster-Objekt hält.

class Singleton
{
   public:
     static Singleton* exemplar();

   private:
     static Singleton *instanz;
     Singleton() {}
     Singleton( const Singleton& );

     ~Singleton() {}

     class Waechter {
         public: ~Waechter() {
           if( Singleton::instanz != 0 )
             delete Singleton::instanz;
         }

         void destroy()
         {
           if ( !Singleton::instanz )
           {
             delete Singleton::instanz;
             Singleton::instanz = 0;
           }   
         }
     };
     friend class Waechter;
};

Somit könnte man das Singleton selbst zerstören, wenn das irgendwie notwenig ist, und wenn man es verigsst wird es automatisch gemacht.

Ich finde mittlerweile sogar globale Variablen besser als Singletons.

Und ich find Vanilleeis ganz Klasse.
Mal ehrlich: hier sollte es weniger darum gehen was man an persönlichen Präferenzen für und gegen ein bestimmtes Pattern hat, sondern vielmehr darum, welche Vor- und Nachteile das Pattern in der gegebenen Situation gegenüber den Alternativen hat. Deswegen sollte zu jedem "ich finde" auch ein "weil" geliefert werden. Und zwar nicht "weil Vanilleeis einfach lecker ist".

Wenn ich das wie im Meyer Singleton mache (also eine Referenz auf eine statische lokale Variable liefere), wo ist dann das Problem?
Erzeugung: Nur wenn man die statische Funktion aufruft, wird das Objekt erzeugt. Passt.
Zerstörung: Ok da bin ich etwas überfragt. Finde eine statische lokale Variable eh irgendwie magisch. Wann wird diese Variable denn wieder zerstört? Und was genau ist jetzt dieses Zerstör-Problem? Kann da vielleicht jemand bitte ein kleines Beispiel bringen?

Das Problem ist die Reihenfolge, in der zerstört wird, wenn du 2 statische Variablen hast. Was passiert z.B, wenn die einte zerstört wird und die andere bei seiner eigenen Zerstörung auf die bereits zerstört zugreift?

Seh da noch immer nicht das Problem. Dann greif ich einfach in den Destruktoren der Singletons auf kein anderes Singleton zu. Dann is doch alles sicher?

Sofern das möglich ist, was aber nicht immer geht. Ich würde das Problem als sehr selten bezeichnen, aber es kommt tatsächlich manchmal vor.
Deshalb hatte drakon auch gesagt, dass in den meisten Fällen das Meyers Singleton absolut ausreicht.

Grüssli

Seh da noch immer nicht das Problem. Dann greif ich einfach in den Destruktoren der Singletons auf kein anderes Singleton zu. Dann is doch alles sicher?

Jup. Nur kann man sich da manchmal nicht sicher sein, zum Beispiel hast Du irgendwann Sorgen mit dem Drucker und machst zur Sicherheit mal rein, daß die Druckerdestruktion geloggt wird. Hast aber vergessen, daß nicht nur der Drucker ein Singleton ist, sondern das LOG-Makro innendrin auch einen Singleton verwendet. Schade.
Aber will man ALLES bedenken im Umgang mit Singletons, hat man irgendwie einen gewissen Spaßverlust.