Bruno wrote: ...
Yep precisely because the concept literally says "there must exist a specialization of point_traits with X such that this code is valid". It's finally as much a "point traits concept" as a "point concept". Maybe it would be better to have X being the specialized point_traits? It would require an additional point_type typedef in the point traits and would give something like:
template <class X> // X is a point_traits struct PointTraits { typedef typename X::coordinate_type ctype; enum { ccount = X::coordinate_count };
template <int I, int Count> struct dimension_checker { static void check() { const typename PT::point_type* point; ctype coord = X::template get<I>(*point); typename PT::point_type* point2; X::template get<I>(*point2) = coord;
dimension_checker<I+1, Count>::check(); } };
template <int Count> struct dimension_checker<Count, Count> { static void check() {} };
BOOST_CONCEPT_USAGE(Point) { dimension_checker<0, ccount>::check(); } };
Then, requirements inside algorithms would be done this way:
template <class P> BOOST_CONCEPT_REQUIRES( ((PointTraits<point_traits<P> >)), (void)) function_requiring_a_point(const P& p) {}
Well, if we agree that traits at least have the _potential_ to cause an issue then why make the approach _more_traits based?
It doesn't sound clearer to me though... If it's not what you were expecting, could you propose another concept definition?
I like most of what you have, and I am trying to get you guys to do the thinking so I dont have to ;) I'll work something up and send a link when I get a chance, but I think that it will take some work and testing. -- John