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