Date: 2001-08-21 11:53:29
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "William Kempf" <williamkempf_at_h...>
> > (1) I totally don't follow this. The term "surrogate" doesn't
> > apply, so I don't know what you mean by that. In any event, with
> > std::fstream "there can be many such objects" and they are "first
> > citizens". I truly don't see any problem here.
> The default-constructed thread objects are more constrained in their
> functionality than the "primary" thread object - by which I mean
> that started the thread.
Ahhh. Well, the only real restriction is that you can't call join.
I'm not sure that this is that big of an issue.
> The only thing you can do with a default-constructed thread object
> compare it for (in)equality.
Currently. As we add functionality to boost::thread, such as being
able to change it's priority, this will no longer be the case. The
only restriction is calls to join.
> BTW did you consider adding
> bool is_current() const;
> to boost::thread? This would eliminate the need for default-
> thread object most of the time.
Yes, this was discussed. It won't eliminate the need "most of the
> > Please, step back and try to illustrate, hopefully through code
> > where you think there are design flaws here.
> With this defensive attitude we'll never go anywhere. I'm not
> "design flaws," merely different properties and tradeoffs.
I did not mean to be defensive. I was asking you to illustrate with
code where the design was lacking, meaning where you found it
difficult to do something. I wasn't following your arguments well
enough to understand what you were trying to convey, and code conveys
things better than anything else. If you find there are things
difficult to accomplish then I sincerely do want to hear about them
with the goal to insure that the interface doesn't cause any problems
with typical (or even atypical) usage.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk