John wrote:
So in my imagination, CoordinatesConcept and its refinements are what we are talking about. There should be related concepts of PointConcept, VectorConcept, LineConcept, OrientationConcept, RayConcept, IntervalConcept, SegmentConcept and the _real_ killers are probably GeometryConcept and/or CoordinateSystemConcept....
Hmmm, interesting. I've been thinking about a coordinate_traits class similar to the follow to inform the library of various types. template <typename T> struct coordinate_traits {}; template <> struct coordinate_traits { typedef int coordinate_type; typedef unsigned int manhattan_distance_type; typedef double euclidean_distance_type; typedef unsigned long long area_type; ... }; or alternately metafunctions for the same template <typename T> struct area_type {}; //will not compile unless specialized template <> struct area_type<int> { typedef unsigned long long type; } template <> struct area_type<double> { typedef unsigned double type; } Since I need to infer them somehow from the basic coordinate type. That is working under the assumption that all coordinates have the same type, whereas your proposal looks like you want coordinates to be convertable to a scalar type, but allow each Dim to define a different raw_type. What exactly is the value of having different raw types? What I'm doing with my library is basically saying the scalar type is the coordinate type, and you can use whatever data type you want to store the values in your object, but it should convert to and from scalar type to be processed by the library. Is that unreasonable? Thanks, Luke