Subject: Re: [boost] Geometry and spatial indexes, my opinion
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2008-10-09 15:47:55
On Thu, Oct 9, 2008 at 3:36 PM, Simonson, Lucanus J
> --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.
No, it doesn't only work with built-in types. It works with any type
that has the correct operators defined. If the user does care, he can
cast obviously. The algorithm shouldn't do the casting or require it
> The rationale that something is possible, therefore it should be done is
> no rationale at all.
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.
> 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.
> 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.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk