Boost logo

Boost :

Subject: Re: [boost] [guidelines] why template errors suck
From: Eric Niebler (eric_at_[hidden])
Date: 2010-09-24 23:51:14


On 9/24/2010 9:37 PM, David Abrahams wrote:
> On Sep 24, 2010, at 8:41 PM, Eric Niebler wrote:
>> Certainly Concept_check or something like it has a big role to play in
>> this. But I wouldn't know how to use Concept_check to verify that an
>> expression template matches a grammar, for instance. It's not the whole
>> story. Though perhaps I don't know enough about the concept_check
>> library to see how it can apply to proto expressions and grammars.
>> Suggestions?
>
> You'd need to describe adherence to the grammar as a concept. Ultimately, Concept_check relies on the same stuff as BOOST_MPL_ASSERT_MESSAGE: causing a hard error when the concept isn't satisfied. And it does that by crudely attempting to exercise all the compile-time elements of a concept's requirements. So I think your concept would probably end up looking something like:
>
> template <class Expr>
> struct Grammatical
> {
> static_assert(
> proto::matches<Expr, MyGrammar>::value,
> "The expression does not match MyGrammar");
> };
>
> Not very illuminating, is it?

Haha! No, not at all. Let's rephrase the problem a bit. If we still had
C++0x concepts, what would the concept SpiritParser look like, such that
we could define spirit::qi::rule::operator= such that it required its
RHS to satisfy the SpiritParser concept? Would it be any more
illuminating that a simple wrapper around proto::matches<Expr,
SpiritGrammar>?

>> Also, I would prefer C++0x static_assert to the concept_check macros
>> because the error messages can be much nicer. I think the answer is that
>> the concept_check library badly needs a C++0x makeover.
>
> The real challenge would be making it easy to write new concepts. Right now the usage requirements are simple to state, but if you wanted static_assert to fire,
> we'd need to use checks that don't cause errors, e.g. instead of:
>
> same_type(*i++,v); // postincrement-dereference returning value_type
>
>
> you'd have to write something like:
>
> static_assert(
> has_postincrement<InputIterator>::value, "not postincrementable");
> static_assert(
> has_postincrement_deref<InputIterator>::value, "not dereferenceable");
> static_assert(
> is_same<
> postincrement_deref<InputIterator>::type, InputIterator::value_type
> >::value,
> "postincrement dereference doesn't return value_type");
>
> Well, in all, I guess I like the rigor but it's not very compatible with the loosey-goosey C++03 way of specifying concepts <pines for real concept support>.

Blech. Can C++0x SFINAE on expressions make this any nicer? The idea is
to be able to text expressions for well-formedness without causing a
compile error. Then we'd need a way to chain these expressions to make
lists of requirements. Maybe PP sequences consisting of valid
expressions? Is there a compiler that implements this yet so we can play
with it?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk