At Wed, 15 Dec 2010 15:48:31 -0500, Matt Calabrese wrote:
For what it's worth, I do plan on eventually supporting pseudosignatures, though the macro will internally translate the pseudosignature to their corresponding "expression validity check" anyway (but with the added benefit of more likely being able to be translated directly to what may be C++1x concept pseudosignatures, though this is not really my concern for now).
That's fine; the key thing is including the forced type conversions at the function boundaries.
The reason I didn't take this approach from the start is it is much more complicated to preprocess a pseudosignature parameter -- in particular, I'd need special handling of operators (I.E. users would have to spell operator++ as operator pre_inc and the macro internally would have to handle each operator explicitly, which will be a fairly tedious undertaking).
Meh. I guess that wouldn't bother me much.
If you can explain what exactly you feel is problematic with the current approach in more detail I have no problem with eventually scrapping the current interface and only supporting pseudosignatures instead.
Eventually, that's where you should end up, IMO. But that shouldn't impair your progress now if you have momentum. See links in my previous reply for rationale.
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?
As for archetypes do you mean automatically create archetypes?
Yep.
If so, then no. Is this the problem you see with the "valid expression" approach over pseudosignatures?
That's not what I was thinking of, but now that you mention it, yes. I think archetypes are easier to create from pseudosignatures.
I'd imagine that with pseudosignatures it may be possible for me to automatically generate archetypes, though I'd have to give it further thought. That alone is certainly a convincing argument for pseudosignatures, however, I can see the macro getting fairly complicated if such functionality is to be fully-featured. If I do eventually follow that idea, it will likely take quite some time to implement.
No doubt!
As for writing algorithms with the concepts, no, I haven't done so yet other than an Auto_Function "advance" that uses concept-based overloading. Unfortunately, things end up being verbose and loaded with parentheses. Manual tag dispatching ends up being cleaner in practice, so the benefits are questionable.
Oh, that's a shame. You know, with C++0x you also have variadic macros, which could potentially clean up the syntax... or are you already using those?
The main advantage here is that such "category" types that are used for tag dispatching don't have to be created to begin with since the concepts themselves can be used directly. Here's the "advance" implementation I use for testing. It is actually much more complicated than std::advance because I'm using the return type to determine which overload is picked. Try to look past that complexity since it wouldn't be there in an actual implementation.
Anyway, at the moment such rewrites aren't very interesting except for being able to do concept-based overloads, since currently the only concept maps that are supported are empty concept maps. With regards to the iterator concepts, associated types are still accessed via iterator_traits as opposed to via a concept_map directly because I have yet to fully implement associated types with concept maps. So, at this point, Generic is really only worthwhile for "pretty" asserts and concept-based overloading, though that should hopefully change in the near future.
That's still a significant achievement. Great going! -- Dave Abrahams BoostPro Computing http://www.boostpro.com