On 04/10/10 11:22, David Abrahams wrote:
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.
Yes, I noticed that.
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.
I would imagine that when one is doing concept-based dispatching one would use an outer function which asserted conformance to the least-refined concept, and then forwarded to various implementations for different refinements (e.g. essentially what happens now with iterator traits). That should avoid this particular issue. More problematic (I think) is that the SFINAE-based error messages are probably never going to be as good as from e.g. Boost.ConceptCheck, because they will have to go through some translation layer to make them non-fatal and thus won't be in the 'native language' of compiler errors and won't be closely tied to the source location where the requirements are defined. John Bytheway