Bruno Lalande
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.
I am using Fusion in my code, and I like its design. I am no expert at it but I enjoy what I have been exposed to through Fusion.
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
Frankly, I dont know. My sense is that the pre-C++0x (is it 09?) way of dealing with no concept maps is to express concepts in terms of free functions and metafunctions. It looks like this is how boost libraries like boost Graph or Fusion deal with the issue. Still, I am curious about this approach to faking a concept_map, it looks like it could turn out to be something I like. I just dont want the "point_traits" approach used for adapting (or faking a concept map) to spill over into the concept itself. I continue to think thate the concept checking class should require only metafunctions and free functions if we want to support a nonintrusive way to adapt exising pointtypes. I changed the subject line of the thread to match the discussion (we are talking about how to design point concepst, and concept_maps). -- John