Boost logo

Boost :

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-05-10 19:09:19

Luke wrote:
> >> >yet. There are very valid reasons that the size of a
> coordinate set
> >> >should be specified at compile time for cases other than 2 or 3.
> >>
> >> You would not be using my library with these types, ...
> >
> John wrote:
> >Well then maybe I should back out of this discussion, I am interested
> in
> >a generic geometry library that will provide me with a framework to
> >write algorithms that work with any (or many) external opensource,
> >commercial, or legacy geometry libraries.
> >
> >If that is not an aim of GTL then I appologize for the noise :-)
> That is the aim. I don't want you to back out of the discussion.
> Instead of an n-d point concept, which provides you
> relatively little, why not extend the library to have
> explicit quaternians and homogeneous point concepts and
> algorithms specific to such geometry? Wouldn't that serve
> you better? It isn't my aim to provide those, because they
> are not used in my domain, but I do want to provide a
> framework that can be extended to include geometry that I
> don't personally need.

So in my imagination, CoordinatesConcept and its refinements are what we
talking about. There should be related concepts of PointConcept,
LineConcept, OrientationConcept, RayConcept, IntervalConcept,
and the _real_ killers are probably GeometryConcept and/or

Most of the discussion here has been about coordinates access etc. so
here is a
rough (uncompiled) sketch of how I think a CoordinatesConcept might
look. I
am under the gun at work so If you guys tear into this I may be slow to
respond, but If this approach is appreciated I will eventually put it
into an
svn repo and actually try to compile it :)


namespace geometry {

template<class Coord>
struct Coordinates {
    Coord coord;
    typedef typename scalar_type<Coord>::type scalar;
    ////supporting checks I need to do...
    //BOOST_CONCEPT_ASSERT((Addable<scalar, scalar>));
    //BOOST_CONCEPT_ASSERT((Multiplyable<scalar, scalar>));
    //BOOST_CONCEPT_ASSERT((Sunbtractable<scalar, scalar>));
    //BOOST_CONCEPT_ASSERT((Dividable<scalar, scalar>));
        bool bval;
        bval = ::geometry::is_runtime_indexable<Coord>();
        bval = ::geometry::is_runtime_indexable<Coord>::value;

        size_t dim;
        dim = ::geometry::dimension<Coord>();
        dim = ::geometry::dimension<Coord>::value;
        static_at_checker< geometry::dimension<Coord> >::apply();

    template<class Dim>
    struct static_at_checker {
        Coord coord;
        typedef void
        typedef mpl::prior<Dim>
        typedef typename coordinate_accessor<Coord, static_index >
        typedef typename accessor_type::result_type
        BOOST_CONCEPT_ASSERT((Convertable<raw_type, scalar>));
        //BOOST_CONCEPT_ASSERT((Addable<scalar, raw_type>));
        //BOOST_CONCEPT_ASSERT((Multiplyable<scalar, raw_type>));
        //BOOST_CONCEPT_ASSERT((Sunbtractable<scalar, raw_type>));
        //BOOST_CONCEPT_ASSERT((Dividable<scalar, raw_type>));
        static void apply() {
            raw_type rt = at(coord, static_index());
            scalar st = at(coord, static_index());
            raw_type rt = at<static_index>(coord);
            scalar st = at<static_index>(coord);
    template<> struct static_at_checker <mpl::int_<0> > {
        static void apply(){}



Actually I can already see some things to do better in there but that is

_close_ to how I would do it.

There would be another CoordinateArray concept probably.

In order to adapt I would do something like this perhaps:


namespace geometry{

    //named axises
    namespace axis {
        struct X : mpl::int_<0> {};
        struct Y : mpl::int_<1> {};
        struct Z : mpl::int_<2> {};
        struct W : mpl::int_<3> {};
    //Namespace for nonintrusive customization, not to be called
    namespace adapted {
        template<class Coord> struct is_runtime_indexable
            : Coord::is_runtime_indexable {};
        template<class Coord> struct dimension
            : Coord::dimension {};
        template<class Coord> struct scalar_type
            : Coord::scalar_type {};
        template<class Coord, class Index> struct coordinate_accessor
            : Coord::coordinate_accessor<Index> {};

    //Public interface

    template<class Coord> struct is_runtime_indexable
        : geometry::adapted::is_runtime_indexable<Coord> {};
    template<class Coord> struct dimension
        : geometry::adapted::dimension<Coord> {};
    template<class Coord> struct scalar_type
        : geometry::adapted::scalar_type<Coord> {};
    //Static or dynamic indexing
    template<class Index, class Coord>
            adapted::coordinate_accessor<Coord, Index>::result_type>::
    type at(Coord& coord, Index const& index)
            return adapted::coordinate_accessor<Coord, Index>
                ::apply(coord, index);

    //Static indexing
    template<class Index, class Coord>
    typename enable_if_c< less_<Index, dimension<Coord> >
                        , adapted::coordinate_accessor<Coord, Index>
    type at(Coord& coord)
            return adapted::coordinate_accessor<Coord,


I would also add some other functions (at_c, size, etc) but they would
implimented in terms of what is here.
I think it is a lot like Fusion, but with a requirement that the element
have to be convertable to a common scalar type that supports the right
operations (+-*/=). And then there is the metafunction to determine
whether it
is runtime indexable or not.

Since ::geometry::adapted is a namespace it is easy to add adapted
syntax for
other concepts (like Fusion does).

Since the syntax uses free functions in the ::geometry namespace you can

include files with only the functions & metafunctions you need. (There
will be
 more files in the future, that is bound to happen so we should plan on

Requiring adapted syntax in the ::geometry::adapted namespace is
intended to
help avoid ADL issues etc.

MPL integral constants are used for coordinate access because they are a

convertable to integers, so static indexing should always work whenever
 indexing would.

To be complete there should be header files that adapt Fusion sequences,

tuples, c-arrays and boost arrays, and CGAL points.

-- John

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