From: Philippe Lambert (philippe.lambert_at_[hidden])
Date: 2006-08-02 16:19:35
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.
Of course, I thing that the correct solution is in between, but how to state
it?
If it is a real issue, I would like to read other team opinion, standard,
decision algo or policy... If we are technically totally disoriented, I
would like to be redirected...
Thanks to all
Philippe Lambert