Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-09-25 15:21:55


--- In boost_at_y..., "Scott McCaskill" <scott_at_m...> wrote:
> > A case for signal/broadcast:
> >
> > * Q: Why? A: POSIX.
> >
>
> This (and existing literature) are the strongest arguments in favor
of
> signal/broadcast, IMO.

Personally, I could care less about POSIX. POSIX really is a small
blip on the radar when discussing history. It's ALL the other
libraries, languages and literature that makes this compelling for me.

> > * Q: notify_* readable by non-experts, signal/broadcast not?
> >
> > A:
> >
> > It is a feature that signal/broadcast are unreadable by non-
experts. This
> > causes an immediate task-switch to documentation reading mode.
> >
>
> That borders on intentional obfuscation. Classes and methods
should be
> named according to what they are or what they do, respectively.

And both signal() and broadcast() are meaningful for what is done.
Not as intuitive as the others for newbies, but I find this argument
less compelling then the inertia of historic usage. Again, I can't
state this enough. Newbies should *NOT* be attempting to learn how
to write MT programs by looking at MT code. It's just too
dangerous. Threading is a complex and error prone way of
programming, no matter how intuitive the idea of it is, or how
intuitive the interface names are. And when these newbies go to look
at the literature they will find it confusing that everyone else uses
terminology that we don't use in Boost.Threads.

> > notify_one/notify_all are readable enough that a non-expert would
be
> tempted
> > to _not_ check what their precise semantics are - and get burned.
> >
>
> One could make that argument for any well-named, non-trivial
function. API
> names are meant to be mnemonic, not substitues for documentation.

Exactly, and the vast library of documentation on the concepts (as
opposed to the Boost.Threads library and it's documentation) will use
the names signal() and broadcast().

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk