Einzelkind* Einzelkind::getinstance()
{
     cout << "\nG E T  I N S T A N C E ";
	 if(!instance) instance = new Einzelkind;
	 return instance;
}

So nun sollen wir allerdinsg einen Mechanismus schaffen mit dem man das ganze umgehen kann , also trotz alle dem eine Instanz zu erzeugen .

Ich komm einfach nich drauf wie ich das machen kann...

Ich bräuchte erstmal nur einen kleinen tip , bzw ein Stichwort welches mich auf den richtigen Weg führt ..

Danke

#define private public

oder Adressenraten, reinterpret_cast, memcpy und dergleichen.

Ich würd's mit Adressenraten machen. Leg Dir eine globale Variable an. Du benutzt Einzelkind und Einzelkind benutzt cout. Vermutlich liegt Enzelkond::instance zwischen cout und Deiner globalen Variablen im Speicher. Lauf von Deiner globalen Variablen runter bis nach cout und such nach einem Zeiger, der gleich instance ist. Das löst höchst wahrscheinlich keine Schutzverletzung aus. Schreibe eine 0 rein und hol Dir ein zweites EInzelking mit getinstance.

Auf was will der Prof hinaus?

2. Aufgabe (Abgabe!)
Bei einer Reihe von Anwendungen ist es wichtig sicherzustellen, dass von einer bestimmten Klasse
höchstens eine Instanz existiert. (Beispiele: Klassen, die zustandsgebundene Protokolle mit
peripheren Komponenten abwickeln, oder Klassen, die bestimmte Betriebssystem-Ressourcen
managen).
Entwickeln Sie eine Klasse Einzelkind, die a) instanziierbar ist und b) garantiert höchstens einmal
instanziiert wird. Verhindern Sie, dass mehrere Instanzen, z.B. mittels

Einzelkind e1;
Einzelkind e2;
Einzelkind e3 = e1;

angelegt werden und schaffen Sie einen Mechanismus, trotzdem eine Instanz zu erzeugen.
Hinweis: Geben Sie zur Prüfung im Destruktor irgendeinen String aus. Erscheint der String mehrfach,
haben Sie etwas übersehen.

Ja seine Frage lautet so :

angelegt werden und schaffen Sie einen Mechanismus, trotzdem eine Instanz zu erzeugen.

Das ist doch einfach das getinstance. Bist fertig. Du solltest nie den Singleton aushebeln.

: Verhindern sie das man mehrere Instanzen erzeugen kann
und schaffen sie einen Mechanismus trotzdem eine anzulegen .
:-S oder versteh ich die Frage iwie falsch ...

Im Destruktor will er ja nur einen String ausgegeben haben
...mehr nich . Hab ich auch schon erledigt .

Bin mir jetz aber nicht sicher ob ich den Singleton noch aushebeln soll oder nicht ...ich schreib im am besten mal neh Mail .

: Verhindern sie das man mehr als eine Instanze erzeugen kann
und schaffen sie einen Mechanismus trotzdem eine einzige anzulegen .

Werd euch morgen informieren .

good n8t.

Entwickeln Sie eine Klasse Einzelkind, die a) instanziierbar ist und b) garantiert höchstens einmal
instanziiert wird.

Ich hätte das so verstanden, dass die Klassen einen - public - ctor haben muss. Obwohl ich die Anforderung etwas komisch finde. Allerdings finde ich die Formulierung der Aufgabenstellung so oder so schlecht, da mir nicht 100% klar wäre, was der nun haben will.

Ich hätte vermutlich sowas in der Art abgegeben:

class Foo
{
public:
    Foo()
    {
        if (sm_instanceCount != 0)
            throw std::logic_error("sicher nicht!");

        // ...

        sm_instanceCount = 1;
    }

    // ...

private:
    static int sm_instanceCount;
};

Einzelkind e1;
Einzelkind e2;

Und beide Einzelkinder sind dann identisch. Wobei mir der letzte Satz nicht gefällt

Einzelkind e1;
Einzelkind e2;

Und beide Einzelkinder sind dann identisch.

Warum sollte man sowas tuen wollen? Wenn ich ein Singleton habe und nur mit einem Objekt arbeiten muss/brauch, warum sollte ich dann mit mehreren Einzelkinder rumhantieren wollen, wenn es im Endeffekt doch das gleiche ist. Wäre das nicht unnötige Verwirrung?

l'abra d'or schrieb:

Einzelkind e1;
Einzelkind e2;

Und beide Einzelkinder sind dann identisch.

Warum sollte man sowas tuen wollen? Wenn ich ein Singleton habe und nur mit einem Objekt arbeiten muss/brauch, warum sollte ich dann mit mehreren Einzelkinder rumhantieren wollen, wenn es im Endeffekt doch das gleiche ist. Wäre das nicht unnötige Verwirrung?

Wenn man sich die Aufgabenstellung entsprechend zurechtrückt kann man sich so etwas denken.
Instanziierbar, nur eine Instanz, Mechanismus um trotzdem eine Instanz erzeugen zu können.
Wie gesagt ist es ja auch ein Singleton, der sich aber in der Handhabung von dem gewohnten Zugriff per statischer Methode unterscheidet.

FreakY<3Cpp schrieb:

l'abra d'or schrieb:

Einzelkind e1;
Einzelkind e2;

Und beide Einzelkinder sind dann identisch.

Warum sollte man sowas tuen wollen? Wenn ich ein Singleton habe und nur mit einem Objekt arbeiten muss/brauch, warum sollte ich dann mit mehreren Einzelkinder rumhantieren wollen, wenn es im Endeffekt doch das gleiche ist. Wäre das nicht unnötige Verwirrung?

Wenn man sich die Aufgabenstellung entsprechend zurechtrückt kann man sich so etwas denken.
Instanziierbar, nur eine Instanz, Mechanismus um trotzdem eine Instanz erzeugen zu können.
Wie gesagt ist es ja auch ein Singleton, der sich aber in der Handhabung von dem gewohnten Zugriff per statischer Methode unterscheidet.

Ist dann kein Singleton mehr. Ist dann eine Klasse mit spezieller Handle-Semantik. Ein Smart-Pointer mit Singleton-Factory kombiniert sozusagen.

Ist dann kein Singleton mehr. Ist dann eine Klasse mit spezieller Handle-Semantik. Ein Smart-Pointer mit Singleton-Factory kombiniert sozusagen.

oder kurz gesagt: monostate

Um das mit vielen Verschiedenen Klassen zu machen, kannst Du den friend über ein Template bekannt geben:

template <typename T, class spy = MakeFriends<T> > class Fun
{
public:
    Fun& getInstance()
    {
        if ( instance == 0)
        {
            instance = new Fun();
        }
        return instance;
    }

    Fun& operator () ( void )
    {
        cout << i << " ";
        cout.flush();

        return *this;
    }

private:
    Fun( void ) : i(0)
    {
    }

private:
    T i;
    static Fun* instance; // muss noch extern definiert werden!

    friend typename spy; // to make privates accessible for the spy
};

template <typename U> class MakeFriends
{
public:
    MakeFriends(Fun<U>& u) : m(&(u.i)) 
    {
    }

    U* m;
};

Wo bitte steht denn, dass mehrere Instanzen erzeugt werden sollen? Wo steht, dass Singleton umgangen werden soll? Erzeugen sie eine Instanz!

garantiert höchstens einmal instanziiert wird. Verhindern Sie, dass mehrere Instanzen, z.B. mittels [..] trotzdem eine Instanz zu erzeugen.

Wo bitte steht denn, dass mehrere Instanzen erzeugt werden sollen? Wo steht, dass Singleton umgangen werden soll? Erzeugen sie eine Instanz!

so hab ich das auch verstanden.

allerdings:

Einzelkind e1;
Einzelkind e2;
Einzelkind e3 = e1;

das geht mit nem singleton kaum...
es würde eben nur über pimpl + ref-counting machbar sein - dann wären die instanzen alle die selben. und dafür gibts nich so wirklich nen (sinnvollen) grund...

da dort auch nicht groß und breit was von pseudocode steht, würd ichs doch so blöd machen, dass es mit diesem code-stück geht.
die nächste vorgabe war wiederrum, dass man im dtor eine ausgabe macht - und der nur ein einziges mal aufgerufen werden darf...
ich habe das so verstanden, dass es der dtor von einzelkind sein soll und nicht der dtor der in einzelkind gekapselten klasse...

folglich würd ich dem prof auch ne mail schicken und ne url zu dem thread mitschicken...

bb

das geht mit nem singleton kaum...
es würde eben nur über pimpl + ref-counting machbar sein - dann wären die instanzen alle die selben. und dafür gibts nich so wirklich nen (sinnvollen) grund...

monostate

gibt sehr wohl gruende warum man das so haben will... und refcounting ist nicht notwendig...

monostate

ok - der codeschnipsel würde dennoch nicht die angegebenen forderungen erfüllen.
ich bleibe bei meiner aussage, dass die angaben mit c++ nicht zu implementieren sind, da das hier ja schon gegeben ist:

struct Einzelkind
{
 /*...*/

  static unsigned int dtor_count = 0;

  ~Einzelkind()
  {
    ++dtor_count;
  }
};

/*...*/

int main()
{
  Einzelkind e1;
  Einzelkind e2;
  Einzelkind e3 = e1;

  assert(Einzelkind::dtor_count == 1);
}

bb

hustbaer schrieb:

Ist dann kein Singleton mehr. Ist dann eine Klasse mit spezieller Handle-Semantik. Ein Smart-Pointer mit Singleton-Factory kombiniert sozusagen.

oder kurz gesagt: monostate

monostate verstehe ich anders.

Hier:
Objekt wird mit Erzeugen des 1. Handle initialisiert und mit Zerstören des letzten Handles de-initialisiert.

Monostate:
Evtl. auch "lazy" Initialisierung mit Erzeugen des 1. Handle, aber keine sinnvolle De-Initialisierung möglich, da man damit rechnet dass Client Code andauernd extrem kurzlebige Objekte erzeugt (und eben gleich wieder zerstört).

Ist IMO ein u.U. sehr wichtiger Unterschied.

Hier:
Objekt wird mit Erzeugen des 1. Handle initialisiert und mit Zerstören des letzten Handles de-initialisiert.

Davon steht hier nichts.
Aber auch das ist mit monostate problemlos moeglich.

Monostate:
Evtl. auch "lazy" Initialisierung mit Erzeugen des 1. Handle, aber keine sinnvolle De-Initialisierung möglich, da man damit rechnet dass Client Code andauernd extrem kurzlebige Objekte erzeugt (und eben gleich wieder zerstört).

das ist deine enge definition eines monostates. Aber monostate ist ein Design Pattern, dh es beschreibt nur abstakt eine Loesung fuer ein Problem. Wie du es genau implementierst haengt von der Situation ab.

Monostate:
Evtl. auch "lazy" Initialisierung mit Erzeugen des 1. Handle, aber keine sinnvolle De-Initialisierung möglich, da man damit rechnet dass Client Code andauernd extrem kurzlebige Objekte erzeugt (und eben gleich wieder zerstört).

das ist deine enge definition eines monostates. Aber monostate ist ein Design Pattern, dh es beschreibt nur abstakt eine Loesung fuer ein Problem. Wie du es genau implementierst haengt von der Situation ab.

Dann hatte ich da was falsch verstanden.