Re: Boost.Threads - thread_desc concept

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