Problem mit Forward Declaration bei selbstgeschriebenem shared_ptr
-
wxSkip schrieb:
EDIT: Beispiel:
shared_ptr<MyWidget> widget(new MyWidget); widget.DisableManaging(); widget->SetParent(window); //widget wird von window gemanaged //... widget->SetParent(NULL); widget.EnableManaging();Du könnest weiterhin shared_ptr/weak_ptr verwenden, indem Du
im Child ein weak_ptr zum Parent speicherst und
im Parent ein shared_ptr zum Child speicherstOder Du erfindest diese ganzen Räder nicht alle nochmal neu und nimmst einfach Qt oder gtkmm.
-
wxSkip schrieb:
HighLigerBiMBam schrieb:
wxSkip schrieb:
Dann mach mir einen besseren Vorschlag
divided_ptr
...Ich meinte divided im Sinne von "geteilte Nutzung" nicht wie shared "gemeinsame Nutzung". Ich finde es passend, und außerdem klingt es cool
-
shared heißt doch auch geteilt im Sinne von "geteilte Nutzung". divided heißt für mich klar "getrennt". Selbst falls das Wörterbuch eine andere Bedeutung noch vorschlägt, bin ich dennoch ziemlich sicher, dass das die erste Denotation ist, die man im Kopf hat.
Vll. distributed_ptr?
Ansonsten mostly_shared_ptr oder most_of_the_time_shared_ptr oder sometimes_shared_ptr oder maybe_shared_ptr oder under_certain_circumstances_shared_ptr
-
shared ownership = geteilter Besitz
-
krümelkacker schrieb:
Oder Du erfindest diese ganzen Räder nicht alle nochmal neu und nimmst einfach Qt oder gtkmm.
Ich muss dazu sagen, dass ich shared_ptrs momentan an 2 Stellen verwenden will:
1. Ein Projekt ganz ohne externe Libraries. Bisher verwende ich std::shared_ptr, da ich mit TDM-GCC 4.5.1 arbeite. Ich fände es aber geschickt, wenn das Projekt auch mit Compilern ohne TR1 kompilierbar ist (auch ohne boost). Hier benutze ich manchmal auch rohe Pointer wegen der zyklischen Abhängigkeiten, ich könnte mir aber auch vorstellen, auf weak_ptr umzusteigen.
2. Ein Projekt mit Qt. Dieses Projekt erfordert sowieso C++0x-Support, daher steht std::shared_ptr zur Verfügung. Dort bräuchte ich aber auch diese Managed-Unmanaged-Wechsel. QPointer stellt also 1. keine Bereicherung im Vergleich zu std::shared_ptr dar und 2. erfordert dieser ja, dass nur QObjects als Typ verwendet werden. (was bei mir wahrscheinlich nicht der Fall sein wird)
-
Dann halt andere Vorschläge:
split_ptr forked_ptr separated_ptr cleft_ptr appointed_ptrUnd shared-ownership (mit Bindestrich) ist das Beteiligungsverhältnis. Ich finde nur ein anderes Wort sollte her.
-
Ich plädiere für managed_ptr. (Dass der Pointer sich manchmal nicht managed ist IMHO auch eine Form von Management)
-
Pass bloss auf dass du dir damit nicht selbst in den Fuss schiesst.
Die übliche Vorgehensweise wäre AFAIK den Parent als Raw-Pointer abzuspeichern, und die Klasse von enable_shared_from_this abzuleiten.
Dadurch kann GetParent einen shared_ptr zurückgeben, und man hat trotzdem keinen Cycle.
-
hustbaer schrieb:
Pass bloss auf dass du dir damit nicht selbst in den Fuss schiesst.
Die übliche Vorgehensweise wäre AFAIK den Parent als Raw-Pointer abzuspeichern, und die Klasse von enable_shared_from_this abzuleiten.
Dadurch kann GetParent einen shared_ptr zurückgeben, und man hat trotzdem keinen Cycle.Wie meinst du das? Ich kann ja nicht einfach die ganzen Qt-Klassen ableiten. Geht es dir um die zyklischen Abhängigkeiten (welche ja nicht das Problem waren)?
-
Mir geht es darum:
wxSkip schrieb:
shared_ptr<MyWidget> widget(new MyWidget); widget.DisableManaging(); widget->SetParent(window); //widget wird von window gemanaged //... widget->SetParent(NULL); widget.EnableManaging();
-
Dann verstehe ich nicht, was du gemeint hast.
