Re: [boost] [Polygon] review chapter 2, points

Subject: Re: [boost] [Polygon] review chapter 2, points
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-08-29 23:56:48

Steven Watanabe wrote:
> AMDG
> 
> transform and scale seem to be exactly the
> same except for the name of the function that
> they apply. Are these functions needed at all?
> It doesn't seem like they make anything particularly
> easier. All the real logic is in their arguments.

They are implemented uniformly across all types, for the sake of consistency and intuitiveness.  For points they just use the utility in the transform, but for more complex types there are algorithms.

> I would prefer equivalent or equal instead of
> equivalence.

So would I, as it turns out.  I named it that because the function was a proxy for a generic equivalence operator.  I'm not sure its worth changing at this point though.

> point_3d_concept.hpp
> Since manhattan_distance uses euclidean_distance,
> euclidean_distance should come before manhattan_distance.
> Otherwise it can only be found by ADL.

fixed

> point_3d_concept.hpp:173
> using distance_squared in this way seems wrong.
> distance_squared for a 3d point should not only
> use two dimensions.

It is using the concept system to apply the 2D point concept's distance_squared function on the x and y coordinates of the 3d points to factor out that portion of the work for the 3d euclidean_distance calculation.

> Shouldn't instances of
> typename gtl_same_type<
> point_3d_concept,
> typename geometry_concept<T>::type
>  >::type
> use is_point_3d_concept instead?
> ditto for is_point_concept.

Ideally, yes, this refactoring of compile time logic didn't get done in point_3d_concept for some reason.  The way it is currently implemented works fine, but is a little verbose.

> point_traits.hpp and point_3d_traits.hpp are
> missing #include "isotropy.hpp" which they
> need for the orientation enums.

fixed

> point_3d_data should provide a similar set of functions
> to point_data, x,y,z,operator<, etc.

The point 3d stuff is undocumented and somewhat incomplete.  I tried removing it, but it is coupled into the transform pretty strongly.  It was an experiment to understand how the concept based geometry type system could extend to 3d and beyond.

> I would be more comfortable with the name point instead of
> point_data and point_3d instead of point_3d_data.

Me too.  At the time I wanted to be very explicit about what was a data type, what was a concept tag and what was a traits struct.  It wasn't until *after* I gave myself tendonitis in my fingers that I learned to appreciate shorter names for things.  It is easily solved with some typedefs.  I usually use typedef point_data<int> Point.

Thanks,
Luke