Manually incrementing and decrementing a boost::shared_ptr?

Question

Is there a way to manually increment and decrement the count of a shared_ptr in C++?

The problem that I am trying to solve is as follows. I am writing a library in C++ but the interface has to be in pure C. Internally, I would like to use shared_ptr to simplify memory management while preserving the ability to pass a raw pointer through the C interface.

When I pass a raw pointer through the interface, I would like to increment the reference count. The client will then be responsible to call a function that will decrement the reference count when it no longer needs the passed object.

Answer 1

Maybe you are using boost::shared_ptr accross DLL boundaries, what won't work properly. In this case boost::intrusive_ptr might help you out. This is a common case of misuse of shared_ptr people try to work around with dirty hacks... Maybe I am wrong in your case but there should be no good reason to do what you try to do ;-)

ADDED 07/2010: The issues seem to come more from DLL loading/unloading than from the shared_ptr itself. Even the boost rationale doesn't tell much about the cases when boost::intrusive_ptr should be preferred over shared_ptr. I switched to .NET development and didn't follow the details of TR1 regarding this topic, so beware this answer might not be valid anymore now...

Answer 2

You should do separation of concerns here: if the client passes in a raw pointer, the client will be responsible for memory management (i.e. clean up afterwards). If you create the pointers, you will be responsible for memory management. This will also help you with the DLL boundary issues that were mentioned in another answer.

Answer 3

In your suggestion

The client will then be responsible to decrement the counter.

means that the client in question is responsible for memory management, and that your trust her. I still do not understand why.

It is not possible to actually modify the shared_ptr counter... (hum, I'll explain at the end how to...) but there are other solutions.

Solution 1: complete ownership to the client

Hand over the pointer to the client (*shared_ptr::release*) and expect it to pass the ownership back to you when calling back (or simply deleting the object if it is not really shared).

That's actually the traditional approach when dealing with raw pointers and it apply here as well. The downside is that you actually release ownership for this shared_ptr only. If the object is actually shared that might prove inconvenient... so bear with me.

Solution 2: with a callback

This solution means that you always keep ownership and are responsible to maintain this object alive (and kicking) for as long as the client needs it. When the client is done with the object, you expect her to tell you so and invoke a callback in your code that will perform the necessary cleanup.

struct Object;

class Pool // may be a singleton, may be synchronized for multi-thread usage
{
public:
  int accept(boost::shared_ptr<Object>); // adds ptr to the map, returns NEW id
  void release(int id) { m_objects.erase(id); }

private:
  std::map< int, boost::shared_ptr<Object> > m_objects;
}; // class Pool

This way, your client 'decrementing' the counter is actually your client calling a callback method with the id you used, and you deleting one shared_ptr :)

Hacking boost::shared_ptr

As I said it is possible (since we are in C++) to actually hack into the shared_ptr. There are even several ways to do it.

The best way (and easiest) is simply to copy the file down under another name (my_shared_ptr ?) and then:

• change the include guards
• include the real shared_ptr at the beginning
• rename any instance of shared_ptr with your own name (and change the private to public to access the attributes)
• remove all the stuff that is already defined in the real file to avoid clashes

This way you easily obtain a shared_ptr of your own, for which you can access the count. It does not solve the problem of having the C code directly accessing the counter though, you may have to 'simplify' the code here to replace it by a built-in (which works if you are not multi-threaded, and is downright disastrous if you are).

I purposely left out the 'reinterpret_cast' trick and the pointer offsets ones. There are just so many ways to gain illegit access to something in C/C++!

May I advise you NOT to use the hacks though? The two solutions I presented above should be enough to tackle your problem.

Answer 4

1. A handle?

If you want maximum security, gives the user a handle, not the pointer. This way, there's no way he will try to free it and half-succeed.

I'll assume below that, for simplicity's sake, you'll give the user the object pointer.

2. acquire and unacquire ?

You should create a manager class, as described by Matthieu M. in his answer, to memorize what was acquired/unacquired by the user.

As the inferface is C, you can't expect him to use delete or whatever. So, a header like:

#ifndef MY_STRUCT_H
#define MY_STRUCT_H

#ifdef __cplusplus
extern "C"
{
#endif // __cplusplus

typedef struct MyStructDef{} MyStruct ; // dummy declaration, to help
                                        // the compiler not mix types

MyStruct * MyStruct_new() ;
size_t     MyStruct_getSomeValue(MyStruct * p) ;
void       MyStruct_delete(MyStruct * p) ;

#ifdef __cplusplus
}
#endif // __cplusplus

#endif // MY_STRUCT_H

Will enable the user to use your class. I used a declaration of a dummy struct because I want to help the C user by not imposing him the use of the generic void * pointer. But using void * is still a good thing.

The C++ source implementing the feature would be:

#include "MyClass.hpp"
#include "MyStruct.h"

MyManager g_oManager ; // object managing the shared instances
                       // of your class

extern "C"
{

MyStruct * MyStruct_new()
{
   MyClass * pMyClass = g_oManager.createMyClass() ;
   MyStruct * pMyStruct = reinterpret_cast<MyStruct *>(pMyClass) ;
   return pMyStruct ;
}

size_t MyStruct_getSomeValue(MyStruct * p)
{
   MyClass * pMyClass = reinterpret_cast<MyClass *>(p) ;

   if(g_oManager.isMyClassExisting(pMyClass))
   {
      return pMyClass->getSomeValue() ;
   }
   else
   {
      // Oops... the user made a mistake
      // Handle it the way you want...
   }

   return 0 ;
}

void MyStruct_delete(MyStruct * p)
{
   MyClass * pMyClass = reinterpret_cast<MyClass *>(p) ;
   g_oManager.destroyMyClass(pMyClass) ;
}

}

Note that the pointer to MyStruct is plain invalid. You should not use it for whatever reason without reinterpret_cast-ing it into its original MyClass type (see Jaif's answer for more info on that. The C user will use it only with the associated MyStruct_* functions.

Note too that this code verify the class does exist. This could be overkill, but it is a possible use of a manager (see below)

3. About the manager

The manager will hold, as suggested by Matthieu M., a map containing the shared pointer as a value (and the pointer itself, or the handle, as the key). Or a multimap, if it is possible for the user to somehow acquire the same object multiple times.

The good thing about the use of a manager will be that your C++ code will be able to trace which objects were not "unacquired" correctly by the user (adding info in the acquire/unacquire methods like __FILE__ and __LINE__ could help narrow the bug search).

Thus the manager will be able to:

1. NOT free a non-existing object (how did the C user managed to acquire one, by the way ?)
2. KNOW at the end of execution which objects were not unaquired
3. In case of unacquired objets, destroy them anyway (which is good from a RAII viewpoint) This is somewhat evil, but you could offer this
4. As shown in the code above, it could even help detect a pointer does not point to a valid class