Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-10-16 14:59:52

Barend wrote:
>Besides this, in the past discussions concerning the previous previews,

>and the other submissions, discussions concentrated on the points. How 
>it was modelled and how it should look like. Until now I didn't saw any

>comments on this (besides construction of generic geometry objects).
Can 
>we conclude that the list is now satisfied with the provided point
concept?

       template <> struct access<example_point_1>
       {
         template <int I, typename PP>
         static typename forward_const<PP,
           typename support::coordinate<example_point_1>::type>::type&
         get(PP& p) { return I == 0 ? p.x : p.y; }
       };

No, not really.  First of all, what about constructing and setting
values of the point?  It appears to be missing from the generic
interface.

Also, your get function returns a reference to coordinate.  It should
return by value.  Many legacy point types may have a public API that
prohibits direct access to their members because that is what good
little C++ programmers were taught to do in school.  Those point classes
could not conform to your concept.  A polar coordinate point could give
a Cartesian coordinate view of itself, but not if it has to return is
Cartesian coordinate values by reference.  It could not conform to your
concept either.  A point is not a tuple.  I don't think it is valuable
that tuple conforms to your point concept.  An interval has a low and
high value, could be implemented as a tuple of size two, and would
incorrectly conform to your point concept.  That's not a good thing.  If
you had an interval concept in your geometry you would have to ensure
that it was different from the point concept in some way.  Since you are
defining traits for your geometry objects, why not define their
conceptual type as a trait?

template<> struct geometry_concept<example_point_1> { 
        typdef point_concept type; } 

This takes the guess work out of things and allows you to do tag
dispatching based on conceptual type.

Luke