On Wed, Dec 15, 2010 at 2:07 PM, Dave Abrahams <dave@boostpro.com> wrote:
I have some concerns over the use of valid expressions rather than pseudosignatures; they tend to make it very difficult to write correct algorithms.
I'm not sure I immediately understand your concerns, so please elaborate. 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). 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). 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. 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? If so, then no. Is this the problem you see with the "valid expression" approach over 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. 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. 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. http://codepaste.net/qcz4cq 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. -- -Matt Calabrese