Re: [boost] Geometry Template Library from Intel

From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-05-01 08:41:47

Hi,

>  >- Your library has a limited scope: 2D orthogonal and 45-degree lines.
>
>  >(And its name ought to include some indication of that.)  I would like
>  >to see some exploration of in what way your interface (as opposed to
>  >your algorithms) is tied to this domain, i.e. to what extent your
>  >interface could be re-used for a more general or differently-focused
>  >library.  For example, could you have a Point concept that could be
>  >common with Barend's library, allowing Federico's spatial indexes to be
>
>  >used with both?  Or would do you require (e.g. for algorithmic
>  >efficiency reasons) a point concept that is inherently incompatible?
>
>  For me, requiring a point concept that a has an x() and y() member
>  functions is unnecessary and restricts the usefulness of the library.  I
>  could obviously make such a requirement, but I would prefer to have
>  adaptor functions such as:
>  coordinate_type point_interface<T>::getX(const T& point);
>  which allows compatibility with anyone's point concept, rather than
>  requiring that everyone have syntactically compatible point concepts.
>  Federico's spatial indexes should be compatible with both libraries
>  already, provided they are conceptually 2D points, regardless of what
>  API the provide or concept they model.  Even if I took out the
>  inheritance/casting, I still wouldn't require a specific API on the user
>  type.  Shouldn't generic code ideally work with any type that is
>  conceptually a point, rather than only types that model the point
>  concept they set forth?

The point concept of Barend's library doesn't require any x() or y()
member functions. The fact that the library proposes 2 predefined
point classes, point_xy and point_ll, can be a bit confusing but don't
be fooled: they do *not* represent the point concept, they are only 2
classes that satisfy it. The point concept uses accessors of this kind
:

template <int I> value() const;

In the second preview of the library, there was also runtime indexing
accessors, but they should disappear to only have compile-time
accessors as shown above (I'm currently working on this with Barend).

Also, the point concept as currently defined might be replaced by a
point_traits class usable the same way as what you propose with your
point_interface<T>. It gives something like :
point_traits<T>::value<0>(p) to have the first coordinate of a point
p. The point concept would then follow the exact definition just given
by Phil. Not sure yet this will be done, but it brings a lot of
advantages (non-intrusiveness, possibility of using native arrays as
points, ...).

Regards
Bruno