Hi John, Although I'm not completely aware of the Boost.Fusion design and the techniques you describe, I think I basically got the point about the direction you wish us to take. We'll study this. An issue I've been facing with the point_traits class makes me think that you could be right with your approach of avoiding blob traits. However, I have a question about that. If I foresee what this will look like in C++0x, I can see something very close to the traits approach. If you take a look at Doug's presentation about concepts (http://tinyurl.com/5gbykj), the new-style for loop he talks about (near 36:00) relies on a For concept that allows it to find the begin and end iterators of a sequence and iterate on it. Here is the concept_map that Doug shows to map native arrays to this concept: template <typename T, size_t N> concept_map For<T[N]> { typedef T* iterator; T* begin(T array[N]) { return array; } T* end(T array[N]) { return array + N; } } Structurally, this strongly reminds the point_traits class, for a good reason: I had concept maps in mind when writing it. For example, here is the current specialization of the point_traits class for arrays: template <class T, int N> struct point_traits<T[N]> { typedef T coordinate_type; enum { coordinate_count = N }; template <int I> static T& get(T p[N]) { return p[I]; } };
From my point of view, "struct point_traits<T[N]>" is just a C++03 analogy of "concept_map Point<T[N]>". So my question is: does it make sense to consider being a bad practice something that is the analogy of a future official programming technique? Do you think the analogy I'm making here is just wrong?
Wouldn't it be better to simply state that a do-it-all concept is bad because it will generate blob traits, and should rather be separated into several smaller concepts resulting in several small traits? Bruno