Robert ---
Great questions!
On Sun, Mar 20, 2011 at 3:18 PM, Robert Ramey
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