[C++-sig] alternative smart pointer (intrusive_ptr) example

[David Abrahams]

on Mon Jul 28 2008, Jeff Webb <jeff.webb-AT-nta-inc.net> wrote:

> David Abrahams wrote:
>> on Mon Jul 28 2008, Alex Mohr <amohr-AT-pixar.com> wrote:
>>
>>>>> (2) using a global dictionary to store the Pointee->PyObject mappings
>>>> Isn't this going to incur comparable memory use to shared_ptr?
>>> We use a global table.
>>>
>>> Suppose you have a system where there are hundreds of thousands of
>>> objects and only some small fraction of them are passed to python.
>>>
>>> In this case, adding 8 bytes of overhead to every object versus adding
>>> 8 bytes of overhead to only those objects passed to python can save
>>> 100s of KB of memory.  Perhaps that doesn't sound like a lot these
>>> days, but when your users are always trying to push the hardware and
>>> software as hard as they possibly can, it can definitely make a
>>> difference.
>>>
>>> Formerly I embedded the python objects inside the C++ objects but
>>> switched to the global table due to memory usage.
>>
>> I wasn't talking about adding storage to every instance of a class.
>>
>> Boost.Python converts any wrapped object of type T to a shared_ptr<T>
>> which, when passed back to Python, gets converted back to the original
>> Python object.  The last shared_ptr to that object may be reclaimed when
>> the C++ code is done using it.
>
> It sounds like Alex and I have very similar applications, or at least
> we're thinking along the same lines.  I am using smart pointers for
> memory management within the C++ library itself.  Objects hold smart
> pointers to other objects, and smart pointers to objects are passed as
> arguments to various member functions.  I want these smart pointers to
> be as memory efficient as possible because there will be a lot of
> them.
>
> I also want to be able to expose any of these objects (as well as
> functions that take smart pointers to these objects) to python without
> adding memory overhead to the internal smart pointers or the class
> instances themselves.  As Alex mentioned, adding some overhead to keep
> track of the wrapped objects is acceptable (and probably unavoidable),
> so the global table seems like a good option.

OK.

> To clarify, are you suggesting that I should change my internal C++
> code to use shared_ptrs everywhere, or something else?

Nope, I was forgetting that doubtless also want to use your
Python-exposed API from C++.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com