|
Boost : |
Subject: Re: [boost] [guidelines] why template errors suck
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-04 06:22:26
At Mon, 04 Oct 2010 09:48:12 +0100,
John Bytheway wrote:
>
> On 04/10/10 00:39, Mathias Gaunard wrote:
> > On 28/09/2010 19:14, David Abrahams wrote:
> >> Unfortunately, without real concepts we may not be able to do better,
> >> because the pseudo-signature approach inserts type conversions that
> >> we'd have to write by hand. Now here's an interesting thought: write
> >> a library using TMP that generates "concept wrappers" that will force
> >> the necessary conversions. Would require heavy use of rvalue
> >> references to avoid needless copies. Hmm...
> >
> > A crazy idea if you want to be TMP-heavy: maybe you could represent the
> > valid expressions with Proto and infer an archetype from these.
> >
> > This could provide better syntax than the "operator_increment" thing you
> > suggested in some other part of the thread.
>
> Indeed, I already had that idea, and I implemented a proof-of-concept.
> I guess my posts went unnoticed in this huge sprawling thread. See:
>
> http://article.gmane.org/gmane.comp.lib.boost.devel/208946
> http://article.gmane.org/gmane.comp.lib.boost.devel/208996
>
> As you suggest, I think it should be possible to use a single definition
> to check models against concepts, make archetypes, and do concept-based
> overloading. What I'm not sure is whether (a) it's worthwhile to do it,
> and (b) whether it would be worth attempting the more ambitious "concept
> wrappers" idea Dave suggests above.
One step at a time, maybe. What you did looks good. One thing I
should point out, though, is that SFINAE-controlled overloading and
good error messages from concept checks are not exactly compatible. I
think you need to leave off the SFINAE on the overloads with the
least-refined concepts, somehow, if you want something better than a
ridiculous list of non-matching candidates.
-- Dave Abrahams 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