Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-10-27 12:11:49

Hi Luke,

Sorry for the late reply...

>>If you are talking about using the getter for read access, this way of
>>writing traits specialization is not an obligation and the user can
>>always return by value in his own one.
>
>Except that wouldn't work with library code that used it as an lvalue.

>From my point of view, the result of this get function (ie. the one
that's used for reading in our concept, not for writing) should never
be used as an lvalue. It's not its goal.

> My traits looks like the following:
>
> template <typename T>
> struct point_traits {
>  typedef typename T::coordinate_type coordinate_type;
>
>  static inline coordinate_type get(const T& point, orientation_2d orient) {
>    return point.get(orient);
>  }
>  static inline void set(T& point, orientation_2d orient, coordinate_type value) {
>    point.set(orient, value);
>  }
>  static inline T construct(coordinate_type x_value, coordinate_type y_value) {
>    return T(x_value, y_value);
>  }
> };
>
> This is specifically the Cartesian 2D point traits, the 3D point traits are a different structure.  It needs to be specialized for point types that don't conform to my expected default behavior.  Like Brandon, I provide a construct function that returns a point by value.  I also provide the set function that takes a point by reference, an orientation class encapsulated enum and the coordinate value.  I prefer runtime indexing, as I've mentioned before.

OK then I think a set() function instead of our "get for write" one
would be better, less confusing and less tricky. The construction
mechanism you mention is also very useful indeed, I think we'll
implement one too.

> There is a certain degree of redundancy in the way I define the traits, since construct and set are both ways of getting data into an object.  I think that Brandon may have the right idea with a getter function and a construct function.  It is rare to write to only part of an unknown object type.

It's not that rare, and having to construct a whole new point would be
annoying in those cases. I think the best way is to keep both
approaches.

>
> I conclude that the point accessor should return by value or const reference, and that the traits should also provide a construct function to construct a point from coordinate values.  A given point class should additionally provide an assignment operator and copy constructor to conform to the point concept. If we are able to get away without requiring default constructor that would be a good thing.  For an ND point, the construct function should take an iterator pair over coordinate values and the accessor function must be runtime indexing.

In our compile-time accessing world, it would rather take something
like a fusion vector I guess.

> In looking more at Brandon's code, I have to repeat my observation that he has done an impressive job of defining a generic geometry type system and using boost libraries to do it.  I think that if we make his accessor dimension agnostic (either runtime or compile time indexing) we have a winner.

Indeed, it's a very interesting part of his library. Unfortunately we
really have to find a consensus about the compile-time / runtime
access before we can do anything together... Maybe I will open a new
thread about this precise subject.

Brandon if you read this, there's a typo at 3 places of your code:
"dimenstion" instead of "dimension".

Regards
Bruno