On Sep 24, 2010, at 8:41 PM, 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...
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?
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?
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>. -- Dave Abrahams BoostPro Computing http://boostpro.com