Re: [boost] Geometry and spatial indexes, my opinion

Subject: Re: [boost] Geometry and spatial indexes, my opinion
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2008-10-10 17:09:40

On Thu, Oct 9, 2008 at 4:17 PM, Simonson, Lucanus J
<lucanus.j.simonson_at_[hidden]> wrote:
>
>>> I don't see any value in
>>> carrying the individual coordinate data types through the interface
> into
>>> the algorithms.
>
>>They're already present at compile-time.  No extra work required.
>
> Well, yes and no.  If I want to have a
>
> template <int axis>
> coordinate_type get(const point_type& point);
>
> accessor function I need to go through a lot of work to rewrite it as
>
> template <int axis>
> typename coordinate_type<axis>::type get(const point_type& point);
>
> and the user needs to go through more work to provide both
>
> template<int axis>
> struct coordinate_type<axis> { typedef int type; }
>
> and
>
> struct general_coordinate_type { typedef int type; }
>
> and will generally be puzzled about why the geometry library is so
> complicated to use.

Well, get is already written for Boost.Tuple and Boost.Fusion
sequences.  This works with built-ins, arrays, and user-defined types.

More to the point, if you accept a type that conforms to a Fusion
sequence, you have the types at compile time, and I exaggerated a
little when I said "no extra work" - for user defined types the user
*will* need to adapt his struct using a Fusion macro, but this is a
one-time thing, and I think it's a one-liner.

> You will have to cast at some point to use the value, why is it more
> expensive to cast up front rather than at the last possible moment.
> Assuming the value is going to be used more than once by the algorithm
> it will be cast more than once.  Better to factor that to the front.  A
> smart compiler would actually do that for you.  Futhermore, there has to
> be a teomporary at the interface because as I've just discussed with
> Brandon, there is the clear need to make things like polar points
> conform to Cartesian interfaces, which is incompatible with direct
> access to the data members.  Since we already have to make a temporary
> we should cast at that point instead of having yet another temoporary
> and cast later on.

The return value temporary is present in both cases, unless the
compiler elides that.  I was talking about parameters.  What if the
function takes 5 parameters?  I have to make 5 unnecessary temporaries
just to call it.

--Michael Fawcett