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: Matt Calabrese (rivorus_at_[hidden])
Date: 2010-12-14 07:11:51

On Tue, Dec 14, 2010 at 5:14 AM, Dave Abrahams <dave_at_[hidden]> wrote:

> That said, if all the type difference occurs *within* the decltype
> *and* within the decltype there are no ODR violations, I *think* there
> is technically no ODR violation.  But I suggest asking a real
> hard-core core-language expert on this one if you care about technical
> correctness.
>

This is what I'm currently banking on. I'll post to clc++ and see if anyone
can shed some light here.

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.

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

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. 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.