Subject: Re: [boost] [guidelines] why template errors suck
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-09-24 21:58:26
Eric Niebler wrote:
> On 9/24/2010 8:22 PM, Robert Ramey wrote:
>> Eric Niebler wrote:
>>> This is borderline self-promotion and I fretted posting this. But
>>> we a community of advanced C++ library developers and I'd really
>>> like feedback about these issues. And they really do involve Boost
>>> library development. If we could reach agreement about these
>>> techniques, we might want to integrate them into Boost's coding
>>> guidelines.
>>>
>>> http://www.reddit.com/r/programming/comments/diddg/expressive_c_why_template_errors_suck_and_what/
>>>
>>> Comments?
>>
>> would all this boil down to the following guidlines.
>>
>> a) All template libraries should use boost::concepts ?
>
> 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?
>
> 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.
Hmm - so the above guidline would be sufficient if the
concept_check_library were subjected to a makeover?
Your article makes a point that libraries should check template
parameters. It's my understanding that this is the intention of
boost concept checks. I'm not sure where "verify that an expression
template matches a grammar" fits in here.
>> b) All template libraries should try to factor implemenations so that
>> compile errors are not propagated?
>
> Yes. And: detailed comments should be left near any static assertions
> or concept checks, since that's where the unlucky few will end up.
I've been doing ths all the time. It's more than a few that end up there.
Just to sum up would the following be sufficent to implement your idea?
a) makeover of concept_check
b) wider usage of concept_check
c) refactoring to truncate listings of compiler errors
Obviously I'm trying to boil this down to something that can
be verified in an objective way.
Robert Ramey