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:37:20

Steven Watanabe wrote:
>An algorithm that uses only compile-time indexing is preferable because
>it can work with an arbitrary point class more easily.

>A point class that supports runtime indexing is preferable because
>it works easily with more algorithms.

Most legacy point types don't provide runtime indexing, but that isn't
much of an obstacle to providing runtime indexing accessors to them.

template <>
coord get(point& p, int i) {
        if(i == 0) return p.x();
        return p.y();
}

On the other hand, algorithms that don't take runtime parameters have to
be instantiated for all possible values.  As the number of the
dimensions in the systems goes up it becomes less reasonable to
enumerate dimensions and more likely that the data types are runtime
indexable.

if(i == 0) {
        do_something_algorithmic<0>(point);
} else {
        do_something_algorithmic<1>(point);
}

Even in two dimensions where it is just a matter of where you push the
wrinkle in the carpet, the key difference is that the former goes in one
place while the latter goes everywhere the algorithm is used when the
parameter is a runtime value.  I push the wrinkle under the couch.  In
my application domain, the parameter is typically a runtime value.  

if(preferred_orientation(metal_layer) == HORIZONTAL)
        do_something<0>();
else
        do_somthing<1>();

vs:

do_something(preferred_orientation(metal_layer));

This is an important distinction to my users.  Basically, I pushed down
the runtime index to the lowest level and factor the if statements out
of the high level (user) code.  That leads to better user code, and
improving the quality of the code written in terms of my API by
thoughtful interface design was something I put a lot of work into.

Luke