From: williamkempf_at_[hidden]
Date: 2001-07-02 13:36:02
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
>
> > > class thread_group
> > > {
> > > public:
> > > // all implicit members are fine and useful
> > >
> > > template<class F> void create(F f)
> > > {
> > > v_.push_back(new thread(f));
> > > }
> > >
> > > void join_all()
> > > {
> > > std::vector<thread*>::iterator it = v_.begin();
> > > while (it != v_.end())
> > > {
> > > (*it)->join();
> >
> > Ooops... that's what I get for doing this on the fly. You need
the
> > following line as well:
> >
> > delete *it;
> > > it = v_.erase(it);
> > > }
> > > }
> > >
> > > private:
> > > std::vector<thread*> v_;
> > > };
> >
> > I should also note that this is a poor implementation of a
> > thread_group, the destruction and removal from the group should
> > probably only be done in the object's destructor and no during the
> > call to join_all().
>
> Yep. And some of the implicit members are neither fine nor
useful. :-)
>
> This is not meant to pick on your ability to write bug-free code on
the fly
> in an e-mail. Nobody can do that.
>
> But if you consider "Bill Kempf/Peter Dimov writing code on the fly
in an
> e-mail" as a rough measure of what the "average" C++ programmer is
likely to
> come up with, you'll see that this "unofficial thread_group test"
does
> provide some indications as to which design is less error prone and
easier
> to use.
No, I don't think it illustrates that at all. At best it illustrates
that Boost.Threads should have a thread_group concept to insure
other's don't make this mistake in their own implementations. It
does not argue for a ref-counted design in any way.
Bill Kempf