[boost] [geometry][concept] Whats the best way to fake a concept map? (was RE: [GTL] redesign checked into sandbox

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-05-12 15:22:02

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