Bruno, Bruno Lalande wrote:
Herewith the URL to the second preview of Geodan's Geometry Library, including documentation and examples.
Hello,
Thanks for this submission, I have compiled and run successfully all the examples provided, and had a quick look at the documentation and implementation. What I've seen until now is quite convincing :-)
Good to hear!
Here are a few remarks...
* I think a lot of people will most often choose to initialize their points to 0. Maybe it would be better if the default behavior was init_zero, and to have an additional "init_none" value in the "init" enum, that could be used explicitly when needed? If non-init is the default, I'm already afraid about all the "uninitialized value" bugs that programmers will mistakenly produce...
OK, it is no problem to change that of course.
* Maybe the parameterized constructor of point should be declared explicit, since implicitly converting a scalar to a point is likely to be an unintended error.
Good idea.
* You could take advantage of the "dimension-agnosticness" of your point concept more than you're currently doing in your algorithms. For example, I have rewritten the pythagoras algorithm to make it dimension-agnostic, this way:
template <typename P1, typename P2, size_t I, typename T> struct compute_pythagoras { static T result(const P1& p1, const P2& p2) { T d = p2.template value<I-1>() - p1.template value<I-1>(); return d*d + compute_pythagoras<P1, P2, I-1, T>::result(p1, p2); } };
template <typename P1, typename P2, typename T> struct compute_pythagoras<P1, P2, 0, T> { static T result(P1, P2) { return 0; } };
template <typename P1, typename P2 = P1> struct pythagoras { static inline bool squared() { return true; }
inline distance_result operator()(const P1& p1, const P2& p2) const { typedef typename select_type_traits<typename P1::coordinate_type, typename P2::coordinate_type>::type T;
return distance_result(compute_pythagoras<P1, P2, P1::coordinate_count, T>::result(p1, p2), true); } };
This way you can use pythagoras either with a point_xy or with other point classes of higher dimensions. I've quickly made up a point_xyz class and it worked perfectly after having defined a strategy for it. Every algorithm doesn't have to be that generic, sometimes it just doesn't make sense. But for the simplest ones, and if it's not too much effort, I think it's worth it.
Thanks for your close look and this well looking elaboration! I will replace it. To be honest I've done some experiments, also with a polygon with a compile-time number of vertices. Called it the template <size_t D> gon, so a gon<3> for a triangle, etc. It disappointed me a bit because the compile-time area calculation routine which I drafted turned out to be slower than the runtime version... So it is interesting to test this with Pythagoras as well. However, it's looking beautiful like this. Regards, Barend
Regards Bruno _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ------------------------------------- Barend Gehrels ------------------------------------- Geodan Holding b.v. President Kennedylaan 1 1079 MB Amsterdam The Netherlands ------------------------------------- Tel: +31 (0)20 5711 335 Mob: +31 (0)6 175 447 62 Fax: +31 (0)20 5711 333 ------------------------------------- E-mail: barend.gehrels@geodan.nl Website: www.geodan.nl Disclaimer: www.geodan.nl/disclaimer -------------------------------------