From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-27 16:53:21
> --- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> > From: <williamkempf_at_h...>
> > How important it is that Gary not pay for (possible) reference
> > counting he doesn't need I don't know, so I'll leave it to
> > Gary to actually argue for one of these if he wants. I remain
> > satisfied with interface 2.
> These are all syntactic variations on one design (as you know), and
> the key to focus on here is the syntax using the shared_ptr. This
> gives us creation syntax like this:
> shared_ptr<thread> p(thread::create(proc));
> This is nearly identical to the more intuitive syntax:
> shared_ptr<thread> p(new thread(proc));
But it isn't identical, because the shared_ptr returned by
create() would have a count of two, not one, which count is
decremented when the thread function returns.
Well, a small benefit anyway. It's not my favorite design.
> To me the decision comes down to a simple question. Do we need a self
> () method? If we do, we must go with "Interface 2" since it's the
> only one that will allow for a self() method. If we don't, we should
> probably opt for "Interface 1" since it's conceptually a cleaner C++
> design and easily allows for ref-counted usage through the above
> syntax with no modifications to the interface.
No, it doesn't easily allow for ref-counted usage. Or else
I'm missing something. Perhaps you are assuming that ~thread()
does a detach(), so the extra count is uneeded? And you are
assuming that shared_ptr will be made thread-safe soon enough?
And that we can get by without self()?
And that the Windows implementation of thread::ref would need
to use explicit reference counting anyway, rather than the
(possibly) more efficient DuplicateHandle?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk