AMDG Simonson, Lucanus J wrote:
I suppose it behooves me to apologize as well. I didn't really intend to put words in other people's mouths. I was trying to point out a contradiction in your shared position.
When the argument is that I should provide runtime parameters to the user, but use compile time parameters internally you are exactly advocating code that looks like:
if(condition) point.get<0>() = value; else point.get<1>() = value;
by implication because there is no other way to get information from runtime to compile time than through flow control and enumeration of conditions. Of course, you don't intend to advocate that, but it is the inescapable consequence of moving the parameter to compile time in the design of my library.
I haven't really looked at your library yet. If there is a significant amount of code that can't easily be refactored to use compile time accessors, by all means use runtime access. Note in my earlier message I only intended to claim that algorithms that don't need to deal with dynamic variations of the index, should use compile time access. Actually, I've recently been thinking about whether it's possible to support both forms of access, transparently. p[0] // get the first element using runtime access. p[mpl::int_<0>()] // get the first element using compile time access. Note that if only runtime indexes are provided, the mpl::int_<0>() will implicitly convert to an int.
Moreover, putting the contradiction aside, there is still no argument in favor of compile time parameter. Not even an argument that it improves performance (it doesn't, by the way)
Have you measured the performance when adapting a struct like this: struct Point { int x; int y; }; ? In Christ, Steven Watanabe