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):
> 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:
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.
> 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.
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk