Iterator

[blurry333]

Singleton* x=Singleton::getInstance();

Fehlermeldung:

Fehler 1 error C2440: 'Initialisierung': 'Singleton' kann nicht in 'Singleton *' konvertiert werden

wo wird eigentlich geprüft dass nicht mehr als eine Instanz angelegt wurde ?

[Blackskyliner]

Wie schon 1-2 Posts nach meinem geklärt, hatte ich mich etwas vertan und statt einem Pointer * muss nur eine Referenz & des Variablentyps genutzt werden. Hatte nicht darauf geachtet, das dein getInstance() ja den Typt Singleton& zurück gibt

Dann sollte der Fehler auch weg sein.

Also:

Singleton& s = Singleton::getInstance();

[volkard]

blurry333 schrieb:

wo wird eigentlich geprüft dass nicht mehr als eine Instanz angelegt wurde ?

Vom static.

[blurry333]

int main() 
{ 
Singleton s = Singleton::getInstance();
}

Fehlermeldung:

Fehler 1 error C2248: "Singleton::Singleton": Kein Zugriff auf private Member, dessen Deklaration in der Singleton-Klasse erfolgte.

[unskilled]

da fehtl ja auch nen &

[blurry333]

trotzdem gehts net.

Dann kommt ein Linker fehler

Fehler 1 error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""private: __thiscall Singleton::Singleton(void)" (??0Singleton@@AAE@XZ)" in Funktion ""public: static class Singleton & __cdecl Singleton::getInstance(void)" (?getInstance@Singleton@@SAAAV1@XZ)". pause.obj

[blurry333]

Warum geht das dann..

#include <iostream> 
#include <stdio.h> 

using namespace std; 

int& funk(int& x)
{
	return x;
}

int main()
{
     int p=7;
	int zahl;

    zahl=funk(p);  // obwohl zahl keine Referenz 
	               // funktionierts

}

[unskilled]

1. wieso gehts hier eigtl um singeltons statt iteratoren?

2. nachdenken 4tw...

struct Singleton
{
private:

public:
  Singleton& get_instance()
  {
    static Singleton instance;
    return instance;
  }
};

int main()
{
  Singleton& s = Sinlgeton::get_instance();
}

Bis hierhin ist noch alles klar, richtig?
Jetzt müssen wir allerdings noch dafür sorgen, dass nirgendwo ein anderes Singleton-Objekt erstellt werden kann
Wir müssen also die KOnstruktoren(copy und standard) private machen.
Allerdings müssen wir den standard-CTor auch implementieren, weil wir ihn selbst ja benutzen - und das hast du offensichtlich nicht getan.

bb

PS:
#include <stdio.h> der Header heißt schon seit 11 Jahren cstdio

[Blackskyliner]

Der Linkerfehler kommt dadurch, dass du den Contructor und Destruktor,wie auch den Copykontruktor keinen leeren Body gibst, bzw. ihn nicht implementierst, womit diese vom Linker nicht gefunden werden.

Ergo das hier fehlt:

#include <iostream> 
#include <cstdio> 

using namespace std; 

class Singleton 
{ 
	private: 
		//Konstruktor private, damit man sich keine Instanzen holen kann. 
		Singleton();
		//Den Kopierkonstruktor schützen um zu vermeiden, dass das Objekt unbeabsichtigt kopiert wird. 
		Singleton(const Singleton& cc);

	public: 
		~Singleton();
		static Singleton& getInstance(); 
}; 

Singleton& Singleton::getInstance() 
{ 
	static Singleton instance; 
	return instance; 
}

Singleton::Singleton(){}
Singleton::~Singleton(){}
Singleton::Singleton(const Singleton& cc){}

int main() 
{ 

	Singleton& s = Singleton::getInstance();   

}

[blurry333]

jo jetzt gehts.

warum brauch ich im main unbedingt die Referenz.

Singleton x=Singleton::getInstance(); // geht nicht

Singleton& x=Singleton::getInstance(); // geht

Ok klar ist wenns keine Referenz wär könnte man mehr als ein objekt anlegen.
Aber in meinem obigen Bespiel gings ja auch ohne .

[unskilled]

Blackskyliner schrieb:

Ergo das hier fehlt:

Singleton::Singleton(const Singleton& cc){}

Nein, das hier wird nicht implementiert.

[unskilled]

blurry333 schrieb:

jo jetzt gehts.

warum brauch ich im main unbedingt die Referenz.

Singleton x=Singleton::getInstance(); // geht nicht

Singleton& x=Singleton::getInstance(); // geht

weil du ein singleton _nicht_ kopieren oder zuweisen kannst.

ps: immernoch diese drecks spam-sperre -.-

[Blackskyliner]

Huch, da wahr ich wohl etwas zu übereifrig mit implementieren
Aber ist es nicht eigentlich egal, wenn man den copy private setzt?
Ist es insofern unerwünscht, damit man IN der Singleton nicht versehentlich kopiert?

[blurry333]

hier wird ja auch eine Referenz zurückgeliefert.
Trotzdem gehts.

#include <iostream> 
#include <stdio.h> 

using namespace std; 

int& funk(int& x) 
{ 
	static int z;
    return z; 
} 

int main() 
{ 
     int p=7; 
    int zahl; 

    zahl=funk(p);  // obwohl zahl keine Referenz 
                   // funktionierts 

}

[Blackskyliner]

Du weist eine Referenz zu. d.H. du ruft den Copy-konstruktor von int auf, wenn es denn eine Klasse wäre.

Da der Copy ja von deiner Singleton ja aber vom Konzept her private ist, kann man das nicht machen.

zahl, hält somit nicht die direkte Referenz auf das static Element, sondern eine eigene Kopie.

[blurry333]

OK :)))

[blurry333]

Der CopyKonstruktor wird wohl immer bei der Initialisierung aufgerufen ?

Die Implementierung von Zuweisungsoperator und CopyKonstruktor müßte doch
exakt dieselbe sein ?

[blurry333]

Hab selber gar was gefunden.

Der zuweisungsoperator muss keinen Speicher anfordern.
Beim Copy Konstruktor hingegen existiert noch kein Speicher, da das
Objekt erst angelegt wird.

[unskilled]

Blackskyliner schrieb:

Huch, da wahr ich wohl etwas zu übereifrig mit implementieren
Aber ist es nicht eigentlich egal, wenn man den copy private setzt?
Ist es insofern unerwünscht, damit man IN der Singleton nicht versehentlich kopiert?

wieso sollte man etwas (falsch) implementieren, wenn man es doch gar nicht braucht? so gar: wenn man verhindern will, dass es verwendet wird.
üblicherweise setzt man so gar noch den assignment-operator private (und auch hier implementiert man nichts). ist zwar in meinen augen überflüssig, aber schaden kann auch das nicht.

bb

[unskilled]

blurry333 schrieb:

Hab selber gar was gefunden.

Der zuweisungsoperator muss keinen Speicher anfordern.
Beim Copy Konstruktor hingegen existiert noch kein Speicher, da das
Objekt erst angelegt wird.

von der sache her richtig - allerdings würde ich es eher anders formulieren.
beim =operator muss zuerst das alte objekt zerstört werden und dann kann erst das neue konstruiert werden. (die reihenfolge wird aber oftmals nicht eingehalten, weil er durch das copy-and-swap-idiom(->google) exceptionsicher gemacht werden kann, man keine code-duplizierungen hat und wenn überhaupt allenfalls minimal messbare performance-unterschiede entstehen.
aber wie schon gesagt, solltest du hier weder copyctor noch assignment-op implementieren, sondern einfach nur als private deklarieren.

bb