Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)

Subject: Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)
From: Dave Abrahams (dave_at_[hidden])
Date: 2010-12-15 14:07:20

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_generic_assert.PNG
> 
> 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_generic_rai_concept.PNG

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