Boost logo

Boost :

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


> >- 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, ...).


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