From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-10-04 05:44:36
Simonson, Lucanus J wrote:
> In looking at the recent submissions to boost related to geometry there
> is a fair amount of overlap with our library, particularly in what I
> call the basic types such as point2d. The ideal outcome from my point
> of view is that we all benefit from a synthesis of ideas and craft a
> boost geometry library together that goes beyond the code we will
> initially submit and will continue to be enhanced and extended with the
> participation of the community over time.
Yes, absolutely. We need to decide what the foundations should be, and
the Point type is one of the most basic. Could you post your point2d class?
Some of the choices are:
* Coordinate type: it's pretty clear to me that that should be a
template parameter, for which you can supply an integer, fixed-point or
floating-point type. Some algorithms will depend on particular types
being used, e.g. my space-filling-curves code doesn't work with
floating point, but that doesn't mean we have to prohibit such kinds of
* Homogeneous vs. heterogeneous coordinate types: for example, in a
mapping application, latitude and longitude are (almost) the same type,
whereas altitude has an entirely different range and might benefit from
using a different type e.g. a different fixed-point scale factor. So
do we have one template parameter or n template parameters?
* Fixed or variable number of coordinates: I'm happy with 2d and
sometimes 3d points and using distinct types for them, but some people
think in higher dimensions and need points with arbitrary numbers of dimensions.
* xyz or [n] notation: using .x, .y and .z to access the coordinates
seems simpler to me, but the higher-dimension people would prefer to
use ,  ... [n]. That notation also has the advantage that you
can iterate through the dimensions. Is it possible to support both?
* Accessors or simple variables: should I write p.x or p.x() or
* Member functions or free functions: p.distance_to(q) or
I'm sure there are more.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk