Hi,
On Fri, Feb 10, 2012 at 2:06 AM, Patrick Mihelich <
mihelich@willowgarage.com
> wrote:
> On Thu, Feb 9, 2012 at 12:55 PM, Dirk Thomas <dthomas@willowgarage.com>wrote:
>
>> While I like boost::shared_ptr, it is not always possible to use it
>>> nicely.
>>>
>>> In rviz I have plugin classes which are subclasses of QWidget (from Qt
>>> GUI library). These objects are automatically deleted by Qt when their
>>> parent widgets are deleted. I can be notified of their
>>> deletion by Qt, and call an "unload" or "decrement-reference-count"
>>> function, but it is not easy to use these QWidget pointers inside
>>> boost::shared_ptr without getting double-deletion crashes.
>>>
>>
>> That sounds like a very reasonable use case.
>> Automatically deleting and unloading is a nice feature but might not
>> always be desired.
>> Having the option to get a raw pointer (as before) and take care of
>> garbaging stuff manually would be great.
>
>
> I don't like this, but don't see a clearly better solution.
>
>
I actually think you still can use a shared pointer in that case.
shared_ptr has a overloaded constructor that takes an explicit delete
functor. When the reference count reaches zero, instead of calling delete,
the functor is called.
I'm not sure if that helps here, but I think this is at least a possibility
to consider. Instead of returning a normal pointer where the user has to
calll decrement-reference-count manually, it should be possible to just
have a share_ptr deleter that calls the decrement-ref-count function.
Lorenz
--
Lorenz Mösenlechner | moesenle@in.tum.de
Technische Universität München | Karlstraße 45
80335 München | Germany
http://ias.cs.tum.edu/ | Tel: +49 (89) 289-26910