Re: [boost] [Review] GGL review starts today, November 5th

Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-11-13 13:45:37

Am Wednesday 11 November 2009 23:17:09 schrieb Barend Gehrels:
hi,

> >  - first of all, I'm curious why you chose to use one traits class for
> > each "agnosticism". this differs from the standard library, so I guess
> > there is a specific reason for it?
>
> Yes. It was discussed on the Boost List before. We're conforming to MPL

I see.

> >  - is there a default implementation of the traits classes? I haven't
> > found one in code/coordinate_dimension.
> > this would simplify writing concept models in many cases, especially with
> > 5 different traits for a Point.
>
> But there are registration macro's. They support different use cases. So
> most people will not have problems adapting their classes to the concepts.

I think these macros are unnecessary.
they do not hide implementation details, or simplify type registration beyond 
what would be possible without macros. it is always my intention to avoid 
macros in public interfaces when possible. if you agree with that, you could 
replace them with something like this:

template<typename Geometry>
struct tag{
  typedef typename geometry_traits<Geometry>::tag tag;
};

template<typename Geometry>
struct geometry_traits{
  typedef typename Geometry::tag tag;
  ...
  ...
};

that way you can keep the MPL metafunctions, but the default implementation 
instantiates a traits "blob", whose default implementation in turn gets its 
information from the geometry type itself.

so in most cases, the user can simply add the traits to the geometry type, 
without using macros:

struct my_point{
  typedef point_tag tag;
  ...
  ...
};

or in the case of a legacy point type, specialize one traits class 
(geometry_traits), which isn't much more verbose than the current macros.

these changes could also be implemented easily, since the metafunctions, 
accessed by algorithms, stay the same.

Stefan