Philippe Lambert wrote:
Hello,
We are a large team of C++ developers, using Boost at large. We have a philosophical issue about shared_ptr usage and I'm looking for external inputs.
The 2 clans are opposed about a simple question: "Should we use shared_ptr in the API function signatures of a module (dll or else)". Both clan use a lot of Sutter/Meyers/other gurus and authors citation to support their view.
1- Pros: shared_ptr are everywhere in the current code. It is the best way to prevent resources leaks, it is easy to use, convenient, it is mostly safe. A lot of gurus are saying "use shared_ptr". Preventing them in API will means a lot of .get() in the existing code.
2- Cons: A shared_ptr in the API give the right to the called function to keep a copy (virtually permanently) of the object. It is a bad indication in the contract if the function doesn't need to keep a copy. It tell to the user "take care, I may keep a copy of this and influence his life cycle". If it is not the case, you should tell it in the signature by asking for a const reference or something like it. Also, if the caller have a stack object and want to use an API function which ask for a shared_ptr, he will need to create a copy, or create a shared_ptr with a deactivated destructor... It is not a beautiful thing, both ways.
Haven't you already answered your own question? If a function needs to keep a copy of the pointer to the object, use shared_ptr; otherwise, use a reference.