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
news:002a01c2270d$cd16d940$7772e50c_at_c161550a...
> [...]
> Well, the mechanism that I sent won't compile without partial
specialization.
> 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
me
is that you leak the pointer to create the closure. What would be nice is
if
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
might
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
created
with a shared_ptr, it would also allow safe copying of the closure. If
closure
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
think
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. ;)

Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk