Deserialisierung zu Pointer oder zu Referenz

maus_on_c

Hallo,

Nach der Deserialisierung stehe ich vor der Frage, wie ich die Objekte an weitere Objekte weitergeben kann. Folgendes Beispiel soll die Situation in etwa schildern:

Class C;

Class D : C; // D erbt von Klasse C,
Class E : C; // E erbt ebenfalls von Klasse C,

Class Pool{
map<int, C&> classPool; //Container für alle Klassen Subtyp C

fill(){
 // Gespeicherte Objekte werden geladen und auf die Map gepusht
 D deserialisiertD = D( serinfo1, serinfo2); 
 classPool.push(1, deserialisiertD&); // ist natürlich Blödsinn 
}

Class Controller{ // Der Controller verarbeitet die geladenen Objekte weiter
Pool & pool; 
}

Wie kann ich die deserialisierten Objekte auf die Map zu legen, um sie mit dem dem Controller weiterverarbeiten zu können?

1. Problem: Natürlich kann ich die geladenen Objekte nicht byValue auf die Map pushen, da es sich um Sub-Typen handelt. Das würde schliesslich zu Slicing führen und die Spezialisierung ginge verloren. Richtig?

2. Problem: Auf die Map wie im Beispiel byReference pushen geht ja wohl auch nicht, da die Objekte nach Verlassen der Funktion fill verloren gehen. Richtig?

3. Problem: Sollte ich mit meinen beiden vor gängigen Aussagen Recht haben, bleibt mir nur noch die Möglichkeit mit NEW zu arbeiten. Bis jetzt konnte ich NEW recht gut vermeiden.
Hier stellt sich für mich die Frage ob ich es mit auto_ptr aus STL versuchen oder gleich den shared_ptr von Boost verwenden soll. Wie ist eure Erfahrung?

Seht ihr eine Möglichkeit das Design so anzupassen, dass passByReference oder byValue trotzdem möglich ist?

Danke für die Tipps und Inputs.

varginator

Wenn du in der map nen Zeiger hast

map<int, C*> classPool;

... oder versteh ich grad was falsch?

Gruß Simon

maus_on_c

varginator schrieb:

Wenn du in der map nen Zeiger hast
map<int, C*> classPool;
... oder versteh ich grad was falsch?

Gruß Simon

Danke Simon -> Ja mit dem Zeiger würde es gehen. Wobei sich gleich die Anschluss-Frage stellt, ob man mit "intelligenten" Zeigern arbeiten solle oder nicht.

Aber ich denke auch, ohne Zeiger lässt sich da nicht mehr viel machen.

varginator

Ja, mit "intelligenten" Zeigern wär es warscheinlich einfacher, aber es kommt auch drauf an, ob du die Original Objekte noch benötigst, oder ob sie bei "Beenden der Map" auch gelöscht werden können ...

Gruß Simon

maus_on_c

Die Map überlebt die ganze Laufzeit der Applikation.
Auf der Map würden dann ja eh nur die Zeiger auf die Objekte liegen.

Solange die Zeiger bestehen, würden auch die entsprechenden Objekte bestehen bleiben. Genau was ich will.

Bekomme ich das schon mit auto_ptr aus STL hin oder brauche dazu boost::shared_ptr?

Nexus

std::auto_ptr kann wegen seiner speziellen Kopiersemantik¹⁾ gefährlich in STL-Containern sein. boost::shared_ptr (bzw. std::tr1::shared_ptr ) ist hingegen kein Problem. Auch eine Möglichkeit wäre boost::ptr_map , allerdings bin ich von der Umsetzung nicht sehr begeistert.

_____

Wenn ein std::auto_ptr -Objekt von einem anderen kopiert wird, sind die beiden Objekte danach nicht gleich, weil dem Original der Zeiger entrissen wird. Diese Gegebenheit wird allerdings oft als Axiom angesehen, und kann zu Problemen führen, wenn zum Beispiel lokale Kopien angelegt werden.

maus_on_c

Danke für die Inputs

Habe mich gleich an die Umsetzung mit boost::shared_ptr gemacht.

Das erste Problem stellt sich auch schon: Ich möchte einen Pointer auf this als Parameter einer Funktion weitergeben.

this->attachedDevice.receiveMsg( boost::shared_ptr<ISurveillant>(this));

Wenn ich nun this schön in einen shared_ptr verpacke bekomme ich Probleme -> Nach Verlassen shared_ptr Scope löscht dieser natürlich auch gleich noch this mit. Das verunmöglicht die Rückkehr in das Objekt natürlich. Bang!

Wie verpacke ich this richtig in ein shared_ptr?

Nexus

Vielleicht hilf dir enable_shared_from_this ...

Ansonsten: Für passive, nur verweisende Zeiger brauchst du keine Smart Pointer. Smart Pointer repräsentieren besitzergreifende Zeiger und sind im Normalfall auch für die Löschung der Objekte verantwortlich.