Boost logo

Boost :

From: Arash Partow (arash_at_[hidden])
Date: 2008-03-28 08:56:36

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

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

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)

> intersection_linestring.hpp
> intersection_segment.hpp
The other thing to get right now is terminology,I'm guessing
linestring is meant to be line_segment_string?

Though it looks like you're on the right track!


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.

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