[ros-users] Draft REP: Automatic unloading of libraries for pluginlib

Lorenz Mösenlechner moesenle at in.tum.de
Fri Feb 10 12:32:27 UTC 2012


Hi,

On Fri, Feb 10, 2012 at 2:06 AM, Patrick Mihelich <mihelich at willowgarage.com
> wrote:

> On Thu, Feb 9, 2012 at 12:55 PM, Dirk Thomas <dthomas at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20120210/be5f275d/attachment-0004.html>


More information about the ros-users mailing list