Re: [Boost-users] Boost Concept Library - fusion and other libraries

Subject: Re: [Boost-users] Boost Concept Library - fusion and other libraries
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-03-21 04:01:33

Robert ---

Great questions!

On Sun, Mar 20, 2011 at 3:18 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> this idea is only implemented in graph, icl,
> iterator and range libraries.  Is there a reason for this, or is that it
> just hasn't been done.  If it's the latter, is there a reason I don't see
> anyone on the requesting that libraries include concept checking classes.
> Also, reviewers don't seem to mention the lack of these classes in the
> code - though they complain about it if it's missing from the documentation.
>
> After sort of struggling with the whole concept concept, I'm think I'm
> coming to appreciate it's utility and maybe it's necessity.  But given that
> no one seems to miss it in the boost libraries, I'm concerned that I'm still
> not getting it.

Concepts *in documentation* are essential for a generic library in the
same way that preconditions e.g.

  int f(int* p);  // Requires: p is non-NULL

are essential in the documentation of ordinary libraries: they
describe constraints that the user of the library must satisfy but
that can't entirely be captured by language constructs, so simply
writing down the library interface is insufficient.

[By contrast, there are other constraints on the library's user that
*can* be entirely captured by language constructs -- e.g. in the
example above, that the argument can be converted to an int*; that
information is captured in the parameter type declaration]

Thus, the description of concept requirements in documentation is an
absolute baseline requirement for any generic library.

The BCCL lets us do two things:

1. Check that a large fraction of documented concept constraints are
satisfied and when they are not, generate errors early enough to avoid
deep template instantiation backtraces.  This is analogous to the use
of assertions at runtime.

2. Check that we've actually documented the right constraints <==
**EVERYBODY TENDS TO OVERLOOK THIS ONE, BUT IT HAS THE GREATEST EFFECT
ON LIBRARY QUALITY: YOU SHOULD USE ARCHETYPES!**  This is analogous to
exhaustive random testing at runtime.

With the BCCL, there are two things that prevent us from making
complete checks for concept constraints:

1. In C++03 anyway, there are some syntactic requirements, e.g. the
presence of a certain constructor, that simply can't be checked.

2. Even with all the checking power in the world, you can't check
semantic constraints.  For example, you can't check that operator== is
actually an equivalence relation, as required by the
EqualityComparable concept. **this means that concepts in code can
never be a complete substitute for concepts in documentation **

Thus, it is a "Best Practice" to use concept checks and archetypes,
but not an absolute requirement for generic libraries.  The "whole
concept concept" is not missing at all in most generic Boost
libraries: it's there in the documentation.  The translation (to the
extent possible) of those concepts into tests and checks in code /is/
sometimes missing.

That might be for any number of reasons:
* the library author didn't have time to learn BCCL
* the library author didn't know about BCCL
* the library is used in heavy compile-time code and the cost of
making the concept checks could slow compilation to an unacceptable
degree, and the library author didn't want to ask users to define a
macro to turn them off.

I totally agree that it's a great idea to encourage the use of BCCL in
generic libraries, and using it can help prevent many defects, but I
wouldn't go as far as to say that not using it is, in and of itself, a
defect.

HTH,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com