Bruno Lalande wrote:
Indeed, things have to be clear on that point, and I'm a bit confused about what really constitutes the concept of a point. What I have understood until now is that a class is the point if it exposes: * the value<>() getter and setter * coordinate_type * coordinate_count
This is somewhat correct but might be an over-engineering of things to the point where it may be unuseable to a group of potential users (people that have large data sets that need things done efficiently). I have 10^9 x,y values as doubles give me the convex hull - can you imagine in the overhead if each of those pairs were to be converted to a point_concept/class/instance?
and that besides this, the .x and .y of the point_xy class were just some syntactic helpers provided for an easier external use of this class. But I see that almost all the algorithms use .x and .y, which means that they won't work with the basic concept I just described. Shouldn't all those algorithms be implemented in terms of value<>() accesses ?
intersection_linestring.hpp intersection_segment.hpp The other thing to get right now is terminology,I'm guessing
Actually most algorithm implementations I've seen use index operators thats possibly because the underlying point types were always nD structures so it makes it easy to do something like the following: template<typename T, unsigned int dimension> struct point { T data_[dimension]; }; . . . point<double,101> point101D; These accessor differences can be taken care of with adaptors and such (though there may be a run-time penalty) linestring is meant to be line_segment_string? Though it looks like you're on the right track! Rgds, Arash Partow __________________________________________________ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net