On Tue, Dec 14, 2010 at 5:14 AM, Dave Abrahams <dave@boostpro.com> 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_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... 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.