
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

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.
participants (3)
-
Mikhail Kubzin
-
Peter Dimov
-
Philippe Lambert