From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-06-27 16:53:21
From: <williamkempf_at_[hidden]>
> --- 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?