Re: Boost.Threads condition.html example

From: williamkempf_at_[hidden]
Date: 2001-03-19 09:01:22

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> Comments on the condition.html example code:
> 
> *  Excellent example.  Good work!

Thanks, though Jeremy Siek deserves most of the credit here.

> *  Don't #include <ll/ll.hpp> :-) Not accepted into Boost yet.

Good point, though it's going to needlessly complicate the example to 
use a predicate with out LL or a similar library.  I'm afraid that 
this will scare off users from the predicate version, which is the 
safer version to use.  I'll think about how to rework this with out 
LL and yet try and keep it simple.

> *  Would class buffer be more self documenting if it was specified 
as:
> 
>       class buffer : boost::noncopyable
> 
>     (Not strictly needed because a member is already noncopyable.)

Probably, yes.  I'll do this.  To be honest, details such as this 
were ignored by me simply because it's an example and not meant to 
illustrate producation quality code.  Guess I'm to used to the MS 
style of documenting.  I'll pay better attention to the examples.
 
> *  Several variables could stand self-explanatory/better names.  
Maybe:
> 
>       p    --> next_avail (or end)
>       c    --> first_used (or begin)
>       full --> size_active
>       buf  --> circular_buf
> 
>     full is downright misleading; it sounds like a bool for 
> buf.size()==buf.capacity().

Which is very close to what it's used for, it's just that the buffer 
is circular in nature.  This means that size_active doesn't sound 
right.  However, I see why you don't like full and I'll try and find 
a better name.
 
> *  The predicates (boost::var(ful)< buf.size()) and (boost::var
(full)>0) 
> depend on ll/ll.hpp, so need to be changed:-(
> 
> *  The need for inner scopes in send() and receive() are completely 
> non-obvious (to me, a naive reader).  Are they needed? Why? How to 
know 
> what to include and what to exclude?  Comments should spell out 
answers to 
> those kinds of questions.  These inner scopes are scary as coded, 
without 
> any hint of why they exist.

I'll look into commenting this as well.
 
> *  receiver() currently just knows (via hard coded literal) how 
many 
> elements sender() will send.  That isn't very realistic or robust.  
Better 
> for sender() to notify receiver() of the end, via whatever 
mechanism would 
> be recommended for a real program.

Interesting idea.  The sample was meant to illustrate the monitor 
pattern with a simple program that can be used to _test_ the 
libraries functionality.  As a test I created it in a closed fashion 
by hard coding the number of loops.  Changing this to more closely 
resemble production code may well be beneficial, so I'll do this.

Bill Kempf