Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Barend Gehrels (barend_at_[hidden])
Date: 2008-10-20 04:19:41

Hi Phil,
>
>> Herewith the URL to the third preview of our Geometry Library, 
>> including documentation and examples.
>> http://geometrylibrary.geodan.nl
> - Can you please see if it's possible to make the URL quoted above 
> work better when Javascript is disabled?
As far as I knew, and can see now, there is no Javascript at all in the 
pages. The documentation is generated by Doxygen. It uses css 
stylesheets but no further tricks. Just tried with Lynx and everything 
seems to be all right for me. Do more people have problems with it?

>
> - I note that you're supporting homogeneous coordinates in arbitrary 
> dimensions.  My current requirements are for at least partially 
> heterogeneous coordinates in 2 or 3 dimensions.  Of course you can't 
> support all permutations and combinations of requirements, but you 
> should perhaps qualify some names to indicate their limited scope.
OK, good to clarify this.
> - I have always used a very simple point type: struct point { T x; T 
> y; };.  It seems that I could continue to use "user" code in this 
> style with your library; however, as a potential library author, I 
> need to replace "p.x" with something like "access<P>::get<0>(p)".  I'm 
> not wildly enthusiastic about this verbosity.  I accept that I'm 
> outvoted on this, but I'm going to continue to remind you (all) that 
> I'm unhappy about it.
It is true that you can continue using p.x and p.y, and it is also true 
that if you want to follow the concepts you have to use a more verbose 
style. A shorter variant of that verbose style is:
geometry::get<0>(p), and if you are, as library author, already in the 
namespace geometry it is just get<0>(p). I got used to it. The advantage 
is that the resulting code will support many point types.
> - I have previously noted that you can advertise your distance 
> function as returning a "type convertible to T" in order to avoid 
> unnecessary sqrt calculations while, for example, scanning a list of 
> points to find the one furthest from p.
I just reread your previous note and my answer on it. It is possible 
with the library to avoid square-roots, when you take the implementation 
functions, which is allowed. However, it is interesting and we will 
relook at your alternative.
>
> - I look forward to seeing concepts for shapes.
>
> - Is there a strategy for "within" that can be used when the shapes 
> being tested store their bounding boxes?
It is not yet implemented like this. It is currently not possible 
because the input is a "geometry::polygon<...>"  and not yet a concept. 
But when it is a concept, and we can attach strategies to polygon-types, 
it would be possible and indeed very interesting. I will try to work it 
out as a useful testcase.

Regards, Barend