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

Subject: Re: [boost] Geometry and spatial indexes, my opinion
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-10-09 16:17:53

>> The rationale that something is possible, therefore it should be done
is
>> no rationale at all.

--Michael Fawcett wrote:
>This is a gross misrepresentation of what I said.  I said the end-user
>cares, *and* it's doable, so it should be done.  You only took half of
>what I said.

You are right, I apologize.

>> Heterogeneous coordinates in the interfaces and
>> internals of algorithms is incompatible with runtime accessors to
>> coordinates and high order constructs.

>Algorithms that need runtime indexing should require that concept.

All of my algorithms use runtime indexing, so that might slant my point
of view slightly here.

>> 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.

>> Why not cast them up front in the user-provided
>> accessor functions and let the user who knows and cares what casting
>> they want to get control that.  Having one coordinate data type
within
>> the algorithms *does* make the implementation of those algorithms
>> simpler and simpler is usually something worth pursuing.

>Because the casting and the temporaries it creates is not free,
>neither in terms of speed or storage.

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.

Luke