On Thu, Sep 27, 2012 at 4:00 PM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
I'd probably be more interested in the part of the impl that expands the macro code to implement concepts, not necessarily the pp stuff.
Refer to boost/generic/concept.hpp line 253 BOOST_GENERIC_CONCEPT_IMPL_VALID_ It's probably hard to decipher since, as you probably realize, pretty much everything needs to go into its own, separate metafunction and everything needs to be expanded inside of template specialization argument lists in order for SFINAE to take place, and all of the associated types of the concept need to be template arguments to every single one of those metafunctions for SFINAE to work with them as well. Also, on the macro side, in order to reduce compile times, I avoid making multiple passes over the top-level macro arguments and instead preprocess it all at once, putting code that will eventually go into different locations into different boost preprocessor sequence elements, and then I pull those out individually at the end. This succeeded at greatly reducing compile-times, but it makes the code harder to read.
It might help to start by taking a look at contract/detail/preprocessor/traits/. Also, this is a possible syntax I had in mind for C++0x concept definitions:
http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp_...
Looks great. I'll probably do most of that eventually, but I'd like to save those changes for later, since what is in currently works and I'd rather focus on new features first before I overhaul the interface. I can't speak for this yet because I'm just now looking into C++1y concepts.
Given those that are associated with the paper, I assume that I may be unique in this stance, though I could still be persuaded otherwise. My main concerns are that the C++0x concepts very clearly matched with the notion of archetypes (which I don't think N3351 even mentioned IIRC). When you wrote a C++0x concept, it wasn't all that dissimilar from declaring a type that models that concept, which, in my opinion, is a big advantage, and it is also makes it fairly clear what archetypes you can except from that concept. When I started Boost.Generic, I took the N3351 style approach but was persuaded to adopt pseudo-signatures instead because of the drawbacks of the ad-hoc expression-style approach (not just because it didn't match up with C++0x concepts) so I'm having trouble going back now. As for associated types, it seems like C++1y concepts are just relying on C++98-style template type traits classes, with concepts only doing verification on those type traits. To me this all just seems like a step backward from what would have been C++0x concepts. I look at iterator_traits as being a hack that came about because there is no direct way to properly create concepts and concept maps with associated types in C++98. Now that there is a chance to eliminate the need for it, aside from legacy code, I'd rather not miss that opportunity, especially given that C++0x concepts were very close to being a standard part of the language and essentially removed the need for things such as iterator_traits (not to mention that they removed the need for things like an explicit iterator category, which these new concepts still have to rely on to some extent). So perhaps this is simpler, but it seems to me like it's also less functional, and that is something I don't agree with. The one thing that I'm really a big fan of in N3351 is its considerable use of axioms, but I just don't see any rationale for the drastic departure from C++0x concepts. -- -Matt Calabrese