Robert Ramey wrote:
Julian Gonggrijp wrote:
I think the use of the BCCL (contrary to the use of concepts for documentation) can also have disadvantages, i.e. in terms of maintainability and readability of the code.
Hmmm, to me, they don't make the code less readable. In fact, it's the opposite to me. It's like putting in a comment that the compiler understands.
I think you make very reasonable points, and also Dave Abrahams has already given excellent input in this discussion, but still let me explain a bit more on my point above. If we compare the following two template definitions with the third: // definition 1 template <class ForwardIter> bool some_algorithm (ForwardIter first, ForwardIter last) { /*...*/ } // definition 2 template <class I> // I: ForwardIterator bool some_algorithm (I first, I last) { /*...*/ } // definition 3 template <class I> BOOST_CONCEPT_REQUIRES( ((boost::ForwardIterator<I>)), (bool) ) some_algorithm (I first, I last) { /*...*/ } then surely the former require less brain resources to interpret and are less error-prone to maintain than the latter, while they are not less self-documenting? I think such brain resource requirement effects shouldn't be underestimated. There is also another minor disadvantage of the macro BOOST_CONCEPT_REQUIRES that affects maintainability in some cases: it breaks automatic symbol recognition in avanced text editors like TextWrangler or Notepad++. For developers who tend to use such advanced text editors this will complicate their workflow. You can alleviate the readability and maintainability issue by using BOOST_CONCEPT_ASSERT rather than BOOST_CONCEPT_REQUIRES, but as the BCCL documentation points out you'll lose a lot of the advantages of BOOST_CONCEPT_REQUIRES in that way. boost.org/doc/libs/1_46_1/libs/concept_check/using_concept_check.htm reads:
One of the nice things about the proposed C++0x syntax for declaring concept constrained function templates is the way that constraints are part of the function declaration, so clients will see them. BOOST_CONCEPT_ASSERT can only express constraints within the function template definition, which hides the constraint in the function body. Aside from the loss of a self-documenting interface, asserting conformance only in the function body can undesirably delay checking if the function is explicitly instantiated in a different translation unit from the one in which it is called, or if the compiler does link-time instantiation.
I'm not saying that the BCCL shouldn't be used, in fact I think it definitely /should/ be used in many cases. I'm only saying that application of the BCCL can also have disadvantages, and that the disadvantages can outweight the advantages when the concept requirements are fairly straightforward or when the "raw" compiler errors aren't too hard to interpret. -Julian