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

Subject: Re: [boost] Geometry and spatial indexes, my opinion
From: Brandon Kohn (blkohn_at_[hidden])
Date: 2008-10-09 15:45:19

--------------------------------------------------
From: "Simonson, Lucanus J" <lucanus.j.simonson_at_[hidden]>
Sent: Thursday, October 09, 2008 2:36 PM
To: <boost_at_[hidden]>
Subject: Re: [boost] Geometry and spatial indexes, my opinion

> --Michael Fawcett
>>Boost.Typeof.  Boost.Units also handles this gracefully, but I'm not
>>sure how they ended up solving it.  Regardless, this is not something
>>the end-user cares how it works, just that it works.  It's doable by
>>the library writer, so should be done.
> ...
>>This type of conversion is handled automatically by the compiler in
>>much simpler expressions:
>
> First off, relying on auto casting is a great way to write template code
> that only works when the template parameters are built-in types and
> doesn't even compile when user defined data types are used instead.
> Moreover, compiler always auto-casts built-in to user defined regardless
> of what your intention, and believe me, the user does care.  The
> compiler doesn't always do the right thing by default.
>
> The rationale that something is possible, therefore it should be done is
> no rationale at all.  Heterogeneous coordinates in the interfaces and
> internals of algorithms is incompatible with runtime accessors to
> coordinates and high order constructs.  I don't see any value in
> carrying the individual coordinate data types through the interface into
> the algorithms.  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.
>
> Luke

Definitely. This is the solution I would use to support this. I believe the 
complexity of having N dimensional heterogeneity in any algorithm isn't 
worth pursuing for a general case library. Also there is nothing to stop a 
sub-community from defining traits based access in a similar vein to the 
general case which does support a separate type for each coordinate 
dimension (and the algorithms to support it). Efforts like these could 
certainly coexist side by side without interfering with one another and it's 
likely that the general case can be used as you say. As for the general 
case, there is already enough on the plate to have algorithms which support 
both floating point and integral coordinate types :).

Cheers,

Brandon

> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>