From: Bjorn Karlsson (bjorn.karlsson_at_[hidden])
Date: 2001-07-17 05:49:13
> And a comment from someone who already has an accepted library:
> 1. Will rationa be expected to change to conform?
> 2. Will I be expected to do the work?
> 3. Which bits of the document are mandatory vs optional?
> (Yes, I did read
> the document - admittedly only quickly - and no, it isn't clear).
> I vote for rejection - not because of any particular
> failings, but because I
> don't see the point. (As someone else pointed out, things
> would be different
> if library maintenance was done by the group, rather than by
The answer to question 3 seems to be stated at the beginning of the
"This document is not intended to act as requirements for boost, but as a
set of ``guideposts to uniformity'', for those cases where authors have no
preference or are willing to change. Nobody likes following arbitrary rules,
and when compliance is voluntary, it's likely that nobody will. Therefore,
wherever possible, choices are made with careful attention to engineering
merit and the underlying rationale is presented."
However, there are a lot of absolutes in the document (forbidden, must,
shall etceteras). Typically, I'd say that guidelines should (shall?) not try
to be anything else than - guidelines.
I think there are two ways to separate requirements from guidelines:
1) Keep them in separate documents.
2) Define the terminology and state clearly what constitutes as a
requirement and a guideline.
The point of having these guidelines?
If you use a library (standard or otherwise) the code in that library
effectively becomes a part of your own. It affects maintenance,
comprehension, implementation style etc. All of these are factors that
should be considered before using/integrating any library in any system.
Now, I think most people would hesitate to (heavily) depend on a library
where the coding style was inconsistent. In the case of Boost, there are a
_lot_ of useful libraries - and to users of these libraries they are not
separate concerns - and therefor needs at least a minimum degree of
consistency between them.
For the developer(s) of a library this consistency may not be as appealing,
unless he/she takes on the view of his/her users.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk