Should a library use an interface that uses smart pointers?

Question

Hi, I'm starting to write a library and considering its interface. Previous libraries I've written all use raw pointers (both internally and in its interface), and now I want to try the smart pointer library that comes with VS2010.

1. Should the interface use smart pointers? (Possibly forcing the library users to use smart pointers too?)
2. Would it be messy if the interface uses raw pointers but the library uses smart pointers internally? (Is it even possible? shared_ptr doesn't have a release() method...)
3. Can two c++0x compliant smart pointer libraries (say boost and VS2010) be used interchangeably? (say I use VS2010 to write my library and the users use boost)

Please help :)

Answer 1

1. Depends on the whether you consider #2 or #3 more important.
2. Yes.
3. No, unless they were deliberately designed to.

Answer 2

I would say to use 80-20 rule here. If 80% of clients would be better of using boost/stl/C++ compliant, then please do so. For the rest, you can build adapter layer and move the complexity to that layer. The Adapter design pattern is my favourite for such purposes.

Answer 3

It is imposable to answer those question without understanding a lot more about your design principles and how you expect the library to be used.

So I can only answer based on my experience and how I like my libraries to be used.

1. Yes.
2. Yes. Don't do it.
3. Its probably not a good idea to mix them (though I have never tried).
   But you can compensate for this:
   As most open source is distributed as source you can build your source so that it can be configured for use in many environments.

For Example:

#if   defined(MY_PROJ_SHARED_PTR_FROM_BOOST)

#include <boost/shared_ptr.hpp>
#define MY_PROJ_SHARED_PTR_NAMESPACE    boost

#elif defined(MY_PROJ_SHARED_PTR_FROM_STD)

#include <memory>
#define MY_PROJ_SHARED_PTR_NAMESPACE    std

#elif defined(MY_PROJ_SHARED_PTR_FROM_TR1)

#include <tr1/memory>
#define MY_PROJ_SHARED_PTR_NAMESPACE    std::tr1

#else
#error "MY_PROJ_SHARED_PTR_FROM_<XXX> not defined correctly"
#endif


namespace X
{
    using ::MY_PROJ_SHARED_PTR_NAMESPACE::shared_ptr;
}


int main()
{
    X::shared_ptr<int>  data;
}

I am sure there are other ways to do this.
But it is late.

Answer 4

From a user's point a view I'd say that you just need to be clear in your interface about what you need.

Do you need a copy of the object or just a pointer?

Internally you can probably use the type of pointer that you're most convienant off as long as it don't degrade performance too much and don't cause bugs.

A question to ask is what exactly will you do with that pointer? Will you delete it? Can I change the reference if I update/delete the object (say in the case of a GUI library).

As someone who don't usually use smart pointers when they are not needed seeing too much smart pointers will just tell me you don't pay attention to what you will do and is cause for potential bugs.

As a library user I prefer a crash (when attempting to dereference a clearly invalid pointer) to having an semi-valid pointer around that is not actually what I expect (which I suspect can be a problem with using smart pointers of the shared_ptr kind).