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