From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-05-12 07:27:28
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