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

Subject: Re: [Boost-users] Boost Concept Library - fusion and other libraries
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2011-03-21 09:35:14

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