Iterator

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

padreigh

muss man nicht eigentlich auch noch operator=() überladen? <kram code raus>

class Single{
private:
   Single(){};                  //  can not be called
   Single(Single const&){};     //  can not be copyed
   Single& operator=(Single const&){};  // can not be reassigned

public:
    static Single* getInstance(); 
    // ... methods that make sense ...

private:
    static Single* singled;
};

Single* Single::singled = NULL;

Single * Single::getInstance()
{
    if (! singled) singled = new Single();

    return singled;
}

unskilled

hab ich doch gerade schon geschrieben...

padreigh schrieb:

class Single{
private:
/*
   Single(){};                  //  can not be called
   Single(Single const&){}; //NEIN!
   Single& operator=(Single const&){}; //NEIN!
*/
  Single() {}
  Single(const Single&); //LNK error if called
  Single& operator=(const Single&); //LNK error if called
public:
    static Single* getInstance(); 
    // ... methods that make sense ...

private:
    static Single* singled;
};

Single* Single::singled = NULL;

Single * Single::getInstance()
{
    if (! singled) singled = new Single();

    return singled;
}

Nachteil an dieser Lsg. ist, dass sie nicht thread-safe ist.
die static-Methode ist wenigstens im GCC thread-safe. im msvc glaube ich aber (noch?) nicht.

bb

Tachyon

unskilled schrieb:

[...]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.[...]

Wieso das denn?

ipsec

Tachyon schrieb:

unskilled schrieb:

[...]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.[...]

Wieso das denn?

Mit "altes Objekt" ist das Objekt gemeint, dem ein neuer Wert zugewiesen werden soll. Z.B. muss ein vector in seinem op= zuerst seine alten Elemente freigeben, bevor er die neuen kopieren kann. Im Copy-Ctor entfällt das, da es keine alten Elemente gibt.

unskilled

Tachyon schrieb:

unskilled schrieb:

[...]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.[...]

Wieso das denn?

weil

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

der zuweisungsoperator muss sehr wohl (unter umständen) speicher anfordern.
beim eintritt in den copyctor existiert der speicher genau genommen schon und er muss nur noch initialisiert werden.

bb

Nexus

ipsec schrieb:

Z.B. muss ein vector in seinem op= zuerst seine alten Elemente freigeben, bevor er die neuen kopieren kann.

Nein. Das wäre ganz schlecht im Bezug auf Exceptionsicherheit.

unskilled schrieb:

beim eintritt in den copyctor existiert der speicher genau genommen schon und er muss nur noch initialisiert werden.

Woher kommt der bereits existierende Speicher, wenn er nicht im Kopierkonstruktor angefordert werden muss?

ipsec

Nexus schrieb:

ipsec schrieb:

Z.B. muss ein vector in seinem op= zuerst seine alten Elemente freigeben, bevor er die neuen kopieren kann.

Nein. Das wäre ganz schlecht im Bezug auf Exceptionsicherheit.

Ich meinte das anschaulich: beim op= gibt es noch Elemente, um die sich irgendwie gekümmert werden muss, beim CopyCtor nicht. Wie jetzt die konkrete Implementierung aussieht, weiß ich nicht.