-------------------------------------------------- From: "Mathias Gaunard" <mathias.gaunard@ens-lyon.org> Sent: Thursday, October 09, 2008 11:19 AM To: <boost@lists.boost.org> Subject: Re: [boost] Geometry and spatial indexes, my opinion
Brandon Kohn wrote:
//! Function to find the cross product between two vectors formed by the specified three points which share an endpoint at A. template <typename Point> point_traits<Point>::coordinate_type cross_product( const Point& A,
const Point& B,
const Point& C )
Isn't the result of the cross product a vector/point?
{ typedef cartesian_access_traits<Point > access_traits; boost::function_requires<Point2DConcept<Point> >();
Isn't the cross product 3D-only?
No the cross product is not 3D only. It can be used to calculate the signed area of the parallelogram formed by 2D vectors (the length of the vector which *is* normal to the 2D plane has this value.) This is how it is used here to calculate the orientation using right hand rule convention. This particular implementation is just a 2D specialized version. I have another version for 3D. Higher dimensions could be written using an indexed access scheme. This is all not the point however. The point is that the mechanisms allow one to write the algorithms as they see fit for whatever underlying point type. Perhaps this notion is now a dead horse that has been repeatedly beaten.
Anyway, wouldn't it be better to use SFINAE so that you can overload the algorithm to make it work with other concepts?
This was done for clarity of my point. The actual version is implemented like this: template <typename Point> typename boost::enable_if< boost::is_same< typename point_traits<Point>::dimension_type, dimension_traits<2> >, typename point_traits<Point>::coordinate_type >::type cross_product( const Point& A, const Point& B, const Point& C ) { typedef cartesian_access_traits< Point > access_traits; boost::function_requires< Point2DConcept< Point > >(); boost::function_requires< CartesianCoordinateAccessorConcept< access_traits > >(); typename point_traits< Point >::coordinate_type cross = ( ( access_traits::get_x( B ) - access_traits::get_x( A ) ) * ( access_traits::get_y( C ) - access_traits::get_y( A ) ) - ( access_traits::get_x( C ) - access_traits::get_x( A ) ) * ( access_traits::get_y( B ) - access_traits::get_y( A ) ) ); return cross; }
When I was talking about access like tuple, I meant using compile time indexing via the access traits. One of the main goals of my library is to facilitate use with legacy geometry code (proprietary in my case) simply by specializing access traits. Using access traits results in little constraint on the interface of the underlying point type.
Are you aware of the Fusion sequence concepts? Any type can be made into a fusion sequence non-intrusively.
So there is no need to recreate the get<N> machinery.
There is a need because the access_traits are what define the interface and the coordinate framework, not the point type. This is just an example of how it would be done for that fusion vector type. The access traits would be specialized differently for other types. struct point { double x, double y }; for example would be specialized differently (and more complexly for the access traits class). If you are saying that fusion can be used to make a struct like this one into a sequence with get<I>.. then it seems there is nothing stopping one from implementing the access traits in terms of that. To reiterate, the point isn't to say that fusion::vector3 makes a great concept for how one should define points or that one should constraint point types to use the get< Index >() interface. It is rather to say that the access_traits mechanism allows algorithm writers to accommodate both formats simply by specializing the access traits for whatever point type is used.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost