wahl des richtigen smartpointer

Der richtige smart pointer hat einen Default-Konstruktor, der automatisch eine Instanz des Programmes das man haben möchte erzeugt. Alles andere ist doch nur Augenwischerei.

Skym0sh0

smarter typ schrieb:

Der richtige smart pointer hat einen Default-Konstruktor, der automatisch eine Instanz des Programmes das man haben möchte erzeugt. Alles andere ist doch nur Augenwischerei.

Aber solch ein Smart-Pointer wäre nur Penisverlängerung... Wer braucht sowas?!

Skym0sh0 schrieb:

smarter typ schrieb:

Der richtige smart pointer hat einen Default-Konstruktor, der automatisch eine Instanz des Programmes das man haben möchte erzeugt. Alles andere ist doch nur Augenwischerei.

Aber solch ein Smart-Pointer wäre nur Penisverlängerung... Wer braucht sowas?!

Faule Programmierer mit Freundin.

Skym0sh0

Seit wann haben Programmierer/Informatiker Freundinnen? oO

Und faul sind wir doch alle, per Definition. Und ungeduldig und überheblich...

Skym0sh0 schrieb:

Seit wann haben Programmierer/Informatiker Freundinnen? oO

Und faul sind wir doch alle, per Definition. Und ungeduldig und überheblich...

ist doch einfach...

this->girlfriend = &nadine;
nadine.owner = this;

sooo, bitteschön!

Ja, aber die meisten Programmierer sind Nullen, daher fuehrt das zu Segfaults.

Skym0sh0

Komisch: in der API-Referenz steht, dass Objekte der Klasse Girldfriend bei allen Operationen nicht deterministische Seiteneffekte haben. Unter anderem wird da vor dem vierten Newton'schen Axiom* gewarnt...

*: Für jede männliche Aktion gibt es eine weibliche Überreaktion.

Mit einem Foto von meinem billigen Notebookdisplay könnte ich dieses Mahnmal nun als "Spiegel der Programmiererseele" zu höchstpreisen verkaufen!

ScottZhang

noch smarterer typ schrieb:

Skym0sh0 schrieb:

Seit wann haben Programmierer/Informatiker Freundinnen? oO

Und faul sind wir doch alle, per Definition. Und ungeduldig und überheblich...

ist doch einfach...
this->girlfriend = &nadine;
nadine.owner = this;
sooo, bitteschön!

Da meckert mein Kompiler:

src/main.C:95:9: error: ‘class Programmierer’ has no member named ‘girlfriend’

hustbaer

Aurorer schrieb:

@hustbaer: Kann gut sein, was würdest du konkret verbessern?

* Es wäre schön wenn man mit einer Allokation auskommt (=Objekt und "Owner" werden zusammen allokiert).
* Der PtrIndirection(PtrOwnerBase<U>* sourceBase, MoveTag) Konstruktor ist höchst fragwürdig. Der sollte auch das "Ausnullen" von sourceBase übernehmen - das ausserhalb zu machen ist fehleranfällig.
* Man kann nicht explizit casten (down-/cross-casts).
* Explizites Casten wiederrum kann man nicht einfach nachrüsten, da die PtrIndirection Klasse dabei zu einem Problem wird. (Man hätte dann sehr schnell viele ineinander verschachtelte PtrIndirection Instanzen).
* Die ganze PtrIndirection Klasse ist sowieso höchst unschön, das lässt sich sicher eleganter regeln.
* Das

virtual PtrOwner* clone() const
		{
			assert(pointer);
			return new PtrOwner(cloner(pointer), cloner, deleter);
		}

ist nicht Exception-safe.

Vermutlich noch ein paar mehr Kleinigkeiten, hab nur kurz drübergesehen.

Aber viel weiter oben angesetzt stellt sich die Frage ob die high-level Designentscheidungen überhaupt optimal sind. volkard ist da ja z.B. anderer Meinung. Und ich bin nicht sicher ob er nicht vielleicht Recht hat

Columbo

Bekomme ich noch Feedback für meine Variante?

Arcoth schrieb:

Bekomme ich noch Feedback für meine Variante?

Völliger Quatsch. Sogar falsch, man kann sehr leicht double deletes produzieren.

Columbo

attention vampir schrieb:

Völliger Quatsch.

Wäre fein, wenn du mir den Grund nennst.

Sogar falsch, man kann sehr leicht double deletes produzieren.

Natürlich habe ich Move-Semantik falsch implementiert. (Edit: So gesehen habe ich sie natürlich nicht implementiert, worin auch der Fehler liegt)

Die konkrete Umsetzung interessiert aber (vorerst) nicht so sehr, es geht ja schließlich erstmal um die Idee. Daher würde ich gerne wissen, was an der "Völliger Quatsch" ist.