At Tue, 14 Dec 2010 07:11:51 -0500, Matt Calabrese wrote:
This thread is a bit outdated with regards to the library now. I'll push the latest Boost.Generic and Boost.Auto_Function to the sandbox in the next couple of days. The progress I've made since this thread was posted has been pretty extensive -- I now have concepts in place for all of the iterator concepts and have completed some slick compile-time asserts which tell you exactly why a particular type does not model a given concept, pointing directly to the concept in question and including, in a static_assert, the exact parameter(s) from the BOOST_GENERIC_CONCEPT invocation that the type doesn't satisfy.
That is *sweet*!
Here's a quick couple of screen shots of things in action -- first, a declaration for a user-defined "random access iterator" and an assert that tells why it is not actually a random access iterator (see the commented out lines and the error in the build log -- the first error points directly to the line where the assert appears):
http://img.waffleimages.com/146abf6162ad7becd898ce3e06aae7502963de2d/boost_g...
And here is the actual concept definition. Note that while the first error that appears in the build log points to the assert itself, the lines that tell you what went wrong point you to the concept definition:
http://img.waffleimages.com/75dc253518146071c4a10b63c155d6c893b7ff68/boost_g...
I have some concerns over the use of valid expressions rather than pseudosignatures; they tend to make it very difficult to write correct algorithms. Can you create archetypes from these concept definitions and do compile-time checking of algorithm bodies? Have you tried to (re-)write any interesting algorithms using these concepts?
To see just how closely the above concept resembles the specification of the concept in the standard, check out page 820 in the current working draft.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf
Notice that Boost.Generic is even able to specify the "givens" (r, a, b, n) via "for", which is a bit trickier than you might expect.
Yeah, I saw. I love that.
The reason why they were tricky is because the given names must be dependent since I need to use them with SFINAE. This mean that they can't simply be data members as they often are with BCCL -- instead, they are implicitly converted to be non-type template reference parameters where the type is dependent on another template parameter. Then, all expressions and conditions internally appear in specializations of these templates in a manner similar to Boost.Enable_If usage with type templates. This allows me to check conditions and the validity of expressions all without causing a hard compile-time error. Using that information I then produce a really simple message via static_assert.
Wow.
Anyway, I've said more than I wanted to right now. I didn't expect this thread to be bumped -- I was hoping to post a new thread about all of this once everything was polished and up in the sandbox.
Looking forward to it! -- Dave Abrahams BoostPro Computing http://www.boostpro.com