Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2002-07-09 04:00:01

"Paul Mensonides" <pmenso57_at_[hidden]> wrote in message
> [...]
> Well, the mechanism that I sent won't compile without partial
> Of course, the mechanism could be implemented externally, in terms of
> p->get().
> [...]
> One concern however.... should the closure facility disallow normal
copying if
> it is working in concert with a shared_ptr?

I have no idea! I barely grok the implementation. One thing that worries
is that you leak the pointer to create the closure. What would be nice is
the closure itself contained a shared_ptr! Otherwise, the shared_ptr might
self-delete, and someone might try to call the closure. Of course, this
create a chicken-n-egg problem, but I haven't thought about how it would
actually be implemented. Seems like it could work, though. It seems that
you should only get the raw pointer when you actually call operator() on
the closure. If you stored a shared_ptr instead of a raw pointer when
with a shared_ptr, it would also allow safe copying of the closure. If
could work with both raw pointers and shared_ptr, that would be great.

> Attached is a sample implementation and a test file. I'm sure it can be
> integrated into shared_ptr better than this. :)

It looks great! I'd like to see the shared_ptr guys comment on it, but I
we could use a boost::closure lib regardless. It would be the icing on the
cake if it integrated with shared_ptr. Now all it needs is documentation,
and an implementation for "less capable" compilers. ;)


Boost list run by bdawes at, gregod at, cpdaniel at, john at