What is the correct way to make sure user use shared_ptr and not regular ptr?

Question

In my class the constructor is private and I added a static method "CreateMyClassPtr" that uses the constructor and returns a share_ptr of it.

Is it the correct implementation?

Do you think I even have to make sure that shared_ptr will be used? Should I maybe leave it to the user to decide?

Answer 1

If you going to expose your class to clients, then don't force them to use shared pointers. They know that they create an object and they are responsible for its deletion.

They then easily can write

myfavorite::api::shared_ptr<Class> object(Class::create());

or

std::auto_ptr<Class> object(Class::create());

Answer 2

If you aren't holding onto any copies of it but you want the user to delete the pointed-to-object using delete then you can return a std::auto_ptr by value. It doesn't add any dependencies (auto_ptr is part of the standard) and it makes your interface clearly communicate the requirement that the object needs to be deleted.

If the user wants to, then they can release the pointer and do things manually or move it into their shared smart pointer framework.

Answer 3

Is the element really shared? That is, after creation, do you keep a pointer into the object for your own purposes or are you doing this just to avoid user memory leaks?

If the memory is not actually shared I would not use a shared_ptr. Note that by using shared_ptr as your return type you are forcing the use of both dynamic allocation and a particular implementation of a smart pointer, but limiting the use of the stack for your type and other smart pointer types that might be more appropriate (you cannot extract membership from a shared pointer)

If you really want to make sure that the call will not leak (that is, if the user calls your function the returned memory will be handled 'somehow', you could use std::auto_ptr or boost::unique_ptr (the last one being unstandard even in C++0x). Both solutions allow calling code to extract the pointer from the smart pointer and use a different approach to memory management (even if it can be cumbersome in some cases).

struct type {
   std::auto_ptr<type> create(); 
};
std::auto_ptr<type> ap = type::create();
std::shared_ptr<type> sp( type::create().release() );
type::create(); // will not leak memory
type *rp = type::create().release(); // user specifically requested a raw pointer!

Answer 4

That will work, yes. However, are you sure you need it? There are circumstances where this is appropriate, but you are really limiting your options when you do so. There are other forms of smart pointers users might want to utilize, not to mention that you are eliminating stack-based allocation as an option when you hide your constructors that way.