ich habe eine Frage zu "intrusive reference counting". Ich habe eine Basisklasse Object, von der alle meine Klassen erben. Object besitzt den reference counter sowie die Methoden IncRef() und DecRef(). Der Ctor von Object setzt den reference counter auf 0.

Dann habe ich noch einen Smart Pointer SmartPtr. Der Ctor sieht so aus:

SmartPtr<T>::SmartPtr(T* t) {
m_ptr = t;
if(t) {
   t->IncRef();
}
}

Nun habe ich viele Factorymethoden und ich würde es dem Anwender gerne überlassen, ob er Smart Pointer verwendet oder nicht. Ich wollte meine Factorymethoden eigentlich so designen (hier ein Beispiel mit Foo):

Foo* createFoo(int i) { 
Foo* p = new Foo(i);
p->IncRef();   // Ref count == 1
return p;

// Anwendung:
Foo* f = createFoo(2);  // Foo hat ref count == 1
// Benutze foo
f->DecRef();    // Foo ref count == 0 => delete

Sollte so ja klappen. Das Problem ist nun, wenn der Nutzer optional SmartPtr einsetzt:

SmartPtr p = createFoo(2);

Nach dieser Zeile hat das Foo object aber einen ref count von 2! Es sollte aber eigentlich einen Ref Count von 1 haben.

Ich könnte nun das IncRef() aus der Factory nehmen, dann hat das gelieferte Foo einen ref counter von 0 und der Einsatz von Smart Pointern klappt dann. Allerdings ist die Benutzung ohne Smart Pointer dann wieder umständlich, weil der Anwender dann explizit nach jedem createFoo() ein IncRef() aufrufen müsste um den Zähler auf 1 zu erhöhen.

Ich hoffe ihr versteht mein Dilemma. Hat wer eine Idee, wie ich das lösen könnte, so dass man die gelieferten Objekte manuell aber auch mit SmartPtr verwenden kann?

Wenn du Referencecounting ueber SmartPointer anbietest, dann sollten auch nur diese Referencecounting nutzen (die Faktory sollten den Refcount nicht erhoehen). Desweiteren ... was macht DecRef() wenn der Counter 0 wird. Ich hoffe nicht, das Objekt vernichten. Aus dem Symmetrieprinzip heraus ist nur die Factory fuer das Erzeugen und Vernichten verantwortlich. Also der SmartPointer(oder manuell) sagt factory->destroy( object* ) und setzt den internen m_ptr = 0. Einen interessanten Abschnitt ueber Symmetrie gab es in der ix 4/2009 zu lesen.

Es ist auch keine richtige Factory. Es ist einfach ein Ding, dass Objekte erzeugt. Was mit denen dann passiert ist ihr Wurst (vergleichbar mit den DirectX COM Funktionen wie createDevice(); es gibt da auch kein destroyDevice()).

Wäre das Design am besten, wenn ich also nur noch Smart Pointer zurückgebe?
Also statt dem:

Foo* createFoo(int i) { 
Foo* p = new Foo(i);
p->IncRef();   // Ref count == 1
return p; }

// Anwendung:
Foo* f = createFoo(2);  // Foo hat ref count == 1
// Benutze foo
f->DecRef();    // Foo ref count == 0 => delete

Nur noch das:

SmartPtr<Foo>* createFoo(int i) { 
SmartPtr<Foo>* p = new Foo(i);
return p; }

// Anwendung:
SmartPtr<Foo> f = createFoo(2);  // Foo hat ref count == 1
// Benutze foo

?

DecRef() wird definitiv das Objekt zerstören, wenn ref counter == 0

Dann aendere es. Das ist naemlich im Sinne der Symmetrie schlecht.

Es ist einfach ein Ding, dass Objekte erzeugt. ... vergleichbar mit den DirectX COM

Also ist es doch eine Faktory! Auch ist mir egal wie Microsoft und COM das macht. Auch scheint es sowas wie Release Device zu geben ... aber ich programmiere kein DirectX.

Wäre das Design am besten, wenn ich also nur noch Smart Pointer zurückgebe?

Nein! Sondern so wie ich es beschrieben habe. Methoden fuer Objecterzeugung/-vernichtung und Referencecounting entkoppeln.

Dann aendere es. Das ist naemlich im Sinne der Symmetrie schlecht.

Mir ehrlich gesagt ziemlich egal, was du mit deiner blöden Symmetrie hast. Jeder Reference Counting SmartPtr arbeitet so und fertig.

Also ist es doch eine Faktory! Auch ist mir egal wie Microsoft und COM das macht.

Mir aber nicht, da ich mit COM arbeite. Außerdem ist eine Objektzerstör Funktion völlig überflüssig, wenn man bereits Ref Counting hat.

Nein! Sondern so wie ich es beschrieben habe. Methoden fuer Objecterzeugung/-vernichtung und Referencecounting entkoppeln.

Ich würde gerne noch die Meinung ANDERER User hier hören:)

Ich würde gerne noch die Meinung ANDERER User hier hören:)

Sorry, das ich dein Design nicht so toll finde, aber wenn du nur fuer dein Design gratuliert werden und nicht ueber Aenderungen nachdenken moechtest, bitte ... Da bin ich wirklich der falsche. Auch verbiete ich hier niemanden den Mund.

Desweiteren:

pd3dDevice->Release();
pd3dDevice = NULL;

Google war mein Freund.

Ganz spontan würde ich "createFoo" einen SmartPointer zurückgeben lassen. Oder was spricht dagegen (Reference-Counting ist ja sowieso in den Objekten eingebaut, nicht im Zeiger)?

Reference Counting ist bereits in allen Objekten eingebaut ja. Der Smart Pointer würde lediglich das Reference Counting automatisieren (wenn der Smart Pointer den Scope verlässt, ruft er DecRef() auf usw.)

Ich tendiere mittlerweile auch dazu einen SmartPtr zurückzugeben. Der einzige Nachteil wäre eben, dass der Benutzer nicht mehr ganz so elegant auch ohne SmartPtr arbeiten könnte. Wenn er ohne SmartPtr arbeiten will, würde das dann ja quasi so aussehen:

SmartPtr<Foo> createFoo();

SmatrPtr<Foo> p = createFoo();  // ref count == 1
Foo* f = p.get();               // get() liefert das Objekt, auf das SmartPtr zeigt
f->IncRef();                    // ref count 2. Wird benötigt, weil ja p DecRef() aufruft, wenn es den Scope verlässt

Is also möglich, aber halt net ganz sooo schön.

Desweiteren:

pd3dDevice->Release();
pd3dDevice = NULL;

Google war mein Freund.

Und inwiefern is das hier relevant?
Release() entspricht 1:1 meinem DecRef(). Es gibt ein createDevice() aber kein destroyDevice().

Und inwiefern is das hier relevant?

Du hast mir dem Vergleich COM angefangen, nicht ich.

Jeder Reference Counting SmartPtr arbeitet so und fertig.

Erstens: Das ist falsch. Mir ging es aber auch nicht um den SmartPointer, der kann ruhig das Objekt vernichten, wenn der Zaehler auf null faellt, DecRef() aber nicht.

Mir ging es aber auch nicht um den SmartPointer, der kann ruhig das Objekt vernichten, wenn der Zaehler auf null faellt, DecRef() aber nicht.

Du hast offenbar noch immer nicht verstanden, dass Reference Counting auch ohne Smart Pointer funktioniert. Siehe COM. Du solltest dir wirklich mal boost::intrusive_ptr anschauen, bevor du hier weiter nervst.

Wie gesagt, über Meinungen ANDERER User freu ich mich dennoch;)

Ich tendiere mittlerweile auch dazu einen SmartPtr zurückzugeben. Der einzige Nachteil wäre eben, dass der Benutzer nicht mehr ganz so elegant auch ohne SmartPtr arbeiten könnte.

Er kann ja so oder so nicht ohne SmartPtr arbeiten, da Reference-Counting und Creation/Deletion ja verschmolzen sind (das ist eigentlich nicht sonderlich schön, da muss ich knivil absolut zustimmen).
Ich würde jedenfalls entweder voll auf SmartPtr setzen oder die beiden Konzepte entkoppeln. Ein Zwischending funktioniert imho nicht gut.

Wo ist das denn bitte verschmolzen? Der Benutzer kann vollständig ohne SmartPtr arbeiten.

Foo* f = createFoo(2);  // Foo hat ref count == 1
// Benutze foo
f->DecRef();    // Foo ref count == 0 => delete

Das DecRef ist doch ein SmartPtr-Ding. Ohne SmartPtr sähe es so aus:

Foo* f = createFoo(2);  // Foo hat ref count von "undefiniert"
// Benutze foo
destroyFoo( f );

Und konsequent mit SmartPtr so:

SmartPtr<Foo> f = createFoo();
// Benutze foo
// Hier wird automatisch abgeräumt

Wo ist das denn bitte verschmolzen? Der Benutzer kann vollständig ohne SmartPtr arbeiten.

dann halt intrisive. wenn die klasse die intrusion über sich ergehen ließ, dann soll die factory auch einen smart pointer zurückgeben und nichts anderes. der empfänger des smart pointers und besitzer des objekts kann dann immernoch entscheiden, daß er an seine diener rohe zeiger verschickt, weil er eh der besitzer bleiben will.
normalerweise werden eh nur klassen smartpointerbefähigt, die vermutlich herumgeschubst werden, wie netzwerkpakete oder tokens oder jobs.
außerdem ist ja noch das

Packet* packet=factory.create();//kein smart pointer, ich bin ein berliner tor
foo(); //dadrin passiert ein throw
//speicherloch

Das DecRef ist doch ein SmartPtr-Ding.

Nein, eben nicht! DecRef() und IncRef() sind lediglich 2 Methoden, die eine Oberklasse Object anbietet, von der alle Klassen ableiten. Das hat NICHTS mit einem Smart Pointer zu tun!

volkard schrieb:

dann halt intrisive. wenn die klasse die intrusion über sich ergehen ließ, dann soll die factory auch einen smart pointer zurückgeben und nichts anderes

Japp, so werd ichs jetzt auch machen.

Dafür refCounting ist doch echt nicht nötig...
Foo produziert immer neue Objekte, also eine nicht denkende, blöde factory.
Diese werden dann benutzt. Werden die auch irgendwie weitergegeben? Also im Kontext einer Klasse per getter angeboten? Dann macht ReferenceCounting schon Sinn. Ansonsten ist es nur unnötiger Ballast, und hat mMn nix in der Klasse selber zu suchen.
Außerdem, wenn RefCounting, dann automatisiert. Wenn ein Benutzer deiner Klasse(n) vergisst, die per createFoo erzeugten Objekte per DecRef() freizugeben, oder am Ende meint "Ich hab Pointer, weg damit -> delete foo;", hast du ziemlichen Stress. Memleaks oder SegFault.

Darum würde ich den RefCounter aus dem Objekt rausnehmen und entweder nur Pointer produzieren, und dem User das freigeben überlassen, oder eben gleich nen SmartPointer zurückgeben.

Ich tendiere eher zu normalen Pointern.

Wie wird denn das Objekt vernichtet? Vielleicht so:

delete this

Du bist verdammt!

f->DecRef();    // Foo ref count == 0 => delete

Wie wird denn das Objekt vernichtet? Vielleicht so:

delete this

Du bist verdammt!

Ja klar so. Wo soll das Problem sein?

Foo* f = createFoo(2);

eine Instanz zu erstellen, die man mit

f->DecRef();

wieder löscht. Was spricht denn gegen eine einheitliche Schnittstelle zur Erzeugung und Zerstörung von Instanzen, also etwas wie

destroyFoo(f);

? (Das ist einfach meine Ansicht, ich würde das nie so machen...)

einheitliche Schnittstelle zur Erzeugung und Zerstörung von Instanzen

Das ist das Symmetrieprinzip, von dem ich rede.

Ja klar so. Wo soll das Problem sein?

delete this halte ich fuer grundsaetzlich boese, ganz einfach weil wieder das Symmetrieprinzip verletzt ist. Ein Objekt kann sich nicht selber erzeugen, also sollte es sich auch nicht selbst zerstoeren. Sauber programmiert man anders. Auch kann das Objekt auf dem Stack liegen, was vielelicht hier nicht der Fall sein wird/kann. Auch weiss ich nicht, wie ob Code nach einem delete this (z.B. in Form von einem return) undefiniertes Verhalten erzeugt. Normalerweise ist dieses Konstrukt ueberfluessig und kann durch besseres Programmdesign entfernt werden.

delete this halte ich fuer grundsaetzlich boese, ganz einfach weil wieder das Symmetrieprinzip verletzt ist. Ein Objekt kann sich nicht selber erzeugen, also sollte es sich auch nicht selbst zerstoeren. Sauber programmiert man anders.

Mag sein, aber ich hab mal gelesen, dass wenigstens unter win dies die einzige Möglichkeit ist, ein via LoadLibrary dynamisch geladenes Objekt (Plugin) ordentlich zu löschen, das muss einfach aus dem Speicherbereich der dll heraus geschehen. Weshalb ich mittlerweile im Plugin-Interface den Destruktor + destroy()-Methode private mache und den PluginManager als friend deklariere, welcher seinerseits eine Methode zum löschen anbietet... Damit garantiert nix falsch geht.

hab mal gelesen

Eine etwas schwache Argumentation. Vielelicht war es einfach schlechtes Plugindesign. Und dein Beispiel ist eher speziell. Im Allgemeinen wuerde ich immer nach besseren Moeglichkeiten als delete this suchen. Hier gibt es die bestimmt.

LoadLibrary dynamisch geladenes Objekt

Keine Ahnung wie Windowsprogrammierung so aussieht, aber ladet man nicht Bibliotheken anstatt Objekte?

delete this halte ich fuer grundsaetzlich boese, ganz einfach weil wieder das Symmetrieprinzip verletzt ist. Ein Objekt kann sich nicht selber erzeugen, also sollte es sich auch nicht selbst zerstoeren. Sauber programmiert man anders. (...) Normalerweise ist dieses Konstrukt ueberfluessig und kann durch besseres Programmdesign entfernt werden.

Intrusive Reference Counting ist an sich, von einem bestimmten Standpunkt aus betrachtet, unsauber. Intrusive Reference Counting vermischt Dinge die eigentlich nicht zusammengehören, nämlich die "lifetime control" und das eigentliche Objekt. Es macht die Sache aber nicht besser, die AddRef und Release Funktionen als nicht-Member zu implementieren. IMO macht das die Sache sogar noch schlimmer, denn der Zähler ist Teil des Objekts, also sollte er auch über Member-Funktionen angesprochen werden.

Intrusive Reference Counting ist eine Optimierung, und wie die meisten Optimierungen, streng genommen nicht ganz "sauber". Es ist aber Common Practice und leicht zu verstehen. Daher verstehe ich deine "Bedenken" nicht ganz.

Wenn du es "sauber" willst, dann verzichte ganz auf "Intrusive Reference Counting" ("counted body"), und verwende "counted handle" stattdessen.

Auch weiss ich nicht, wie ob Code nach einem delete this (z.B. in Form von einem return) undefiniertes Verhalten erzeugt.

Es erzeugt kein UB, solange man this danach nichtmehr dereferenziert, oder sonstwie auf Member des Objekts zugreift. Das typische "delete this; return;" ist völlig problemlos.

p.S.: genau das, nämlich dass sich viele Leute nicht sicher sind, ob "delete this" denn "OK" ist, ist der Grund, warum viele Leute es als "böse" verdonnern. Überleg dir mal bessere Argumente, oder hör auf etwas zu verteufeln, was du nicht verstehst.

einem bestimmten Standpunkt aus betrachtet, unsauber.

Ich habe verschiedene Standpunkte probiert, leider ist es bei mir von allen Standpunkten fuer dieses Problem unsauber. Auch moechte ich mich nicht vom Speziellen hier dargestelltem Design zum Allgemeinen wegbewegen.

Intrusive Reference Counting vermischt Dinge die eigentlich nicht zusammengehören

Deswegen ist es schlechtes Design.

AddRef und Release Funktionen als nicht-Member zu implementieren

Darum geht es mir nicht.

Es ist aber Common Practice

Ich verweise da gern auf ein Essay von Paul Graham. Hier ein kleiner Auszug:

Within large organizations, the phrase used to describe this approach is "industry best practice." Its purpose is to shield the pointy-haired boss from responsibility: if he chooses something that is "industry best practice," and the company loses, he can't be blamed. He didn't choose, the industry did.

Wenn du es "sauber" willst, dann verzichte ganz auf "Intrusive Reference Counting" ("counted body"), und verwende "counted handle" stattdessen.

Hier gehts wohl weniger um mich.

p.S.: genau das, nämlich dass sich viele Leute nicht sicher sind, ob "delete this" denn "OK" ist, ist der Grund, warum viele Leute es als "böse" verdonnern. Überleg dir mal bessere Argumente, oder hör auf etwas zu verteufeln, was du nicht verstehst.

Bullshit. Meine anderen Argumente hast du ignoriert. Oder welche sind stark genug? Muss erst der Mond auf die Erde stuerzen ... Die Optimierung halte ich hier fuer fragwuerdig, Common Practice siehe oben auch. Und nur weil etwas kein undefiniertes Verhalten erzeugt, heisst es noch lange nicht, das z.B. delete this "OK" ist. Es ist fast nie okay. Wenn man so argumentiert, dann sollte man auch angehende C++ User nicht darauf hinweisen, dass sie Elemente der Standardbibliothek benutzen sollen, wenn sie im C-Stil programmieren.

Aber glaub was du willst, ich hab grad echt keinen Geist mich mit dir rumzustreiten.

Blub.