
Boost : 
From: Barend Gehrels (barend_at_[hidden])
Date: 20080325 17:08:23
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 noninit 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 "dimensionagnosticness" of your point
> concept more than you're currently doing in your algorithms. For example, I
> have rewritten the pythagoras algorithm to make it dimensionagnostic, 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<I1>()  p1.template value<I1>();
> return d*d + compute_pythagoras<P1, P2, I1, 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
compiletime 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
compiletime 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  Email: barend.gehrels_at_[hidden] Website: www.geodan.nl Disclaimer: www.geodan.nl/disclaimer 
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk