Es ist üblich, enthaltene Objekte als Zeiger auf diese Klasse zu deklarieren, während sie in der Header-Datei "vorwärts" deklariert werden. Dies um physikalische Abhängigkeiten im Code zu reduzieren.
Zum Beispiel
%Vor%Wäre es eine gute Idee, ein solches Member als shared_ptr anstatt als nackter Zeiger zu deklarieren?
Ich würde scoped_ptr bevorzugen, aber AFAIK es wird nicht im Standard sein.
Ja, Sie können (sollten?).
Dies ist eine gängige Praxis . Wie Sie sagten, vermeidet es das explizite Aufrufen von delete ().
Sie können noch weiter gehen. Hier ist ein Beispiel:
%Vor%Was ich so initialisiere:
%Vor% Wenn d_rsa nicht mehr verwendet wird, wird automatisch RSA_free() aufgerufen. Ist das nicht cool?!
Wenn C++11 eine Option ist, sollten Sie besser std::unique_ptr verwenden, die weniger Overhead hat und beweglich ist.
Es hängt davon ab, wie sich Ihre einschließende Klasse in Bezug auf das Kopieren verhalten soll.
Wenn Sie shared_ptr verwenden, können Sie den Besitz an ein anderes Objekt übergeben, so dass es nicht zerstört wird, wenn Ihr äußeres Objekt zerstört wird. Sie erklären, dass dies in diesem speziellen Fall keine Rolle spielt.
Der einzige Vorteil, den ein intelligenter Zeiger haben wird, ist, dass Sie nicht daran denken müssen, ein delete pB in Ihren Destruktor zu setzen. Das kann für die meisten Leute ein ausreichender Vorteil sein.
Wenn Sie sich nicht um Besitzprobleme kümmern müssen, ist sogar ein auto_ptr gut genug.
Im Falle einer Komposition ist es eine gute Idee, wenn Sie keine physische Abhängigkeit wollen. Dann wird dein B automatisch zerstört, wenn A ist.
Wenn Sie keine physische Abhängigkeit haben, können Sie das Datenelement einfach nach Wert halten.
(Sie können auch nach dem Pimpl-Idiom suchen, wenn die physische Abhängigkeit ein Problem ist.)
Tags und Links c++ boost shared-ptr