Boost logo

Boost :

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
(, 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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at