Mechanismus zum Umgehen eines Singletons !

[unskilled]

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]

Shade Of Mine schrieb:

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.

[Shade Of Mine]

hustbaer schrieb:

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.

[hustbaer]

Shade Of Mine schrieb:

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.