
<lucanus.j.simonson@intel.com> wrote:
We both have the same intent of improving programming practices
library development. The way people code geometry typically looks
s J through like:
if(condition) point.x() = value; else point.y() = value;
You are advocating a style:
if(condition) point.get<0>() = value; else point.get<1>() = value;
and I am advocating:
point.get(condition) = value;
Michael wrote:
I don't think Joel, Steven, myself, or anyone else suggesting compile-time indexing is advocating that. I apologize, I shouldn't assume that my view of what Joel and Steven say is any more correct than your view thus far. I would like to retract that and simply state: "I am not advocating that."
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. 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) or that it is easier to use (it isn't.) Just that it "should" be compile time for the sake of "genericity". My question is: to what end? Now I like making the coordinate type a template argument. I was skeptical of that at first. I added that into the design (based upon the community's feedback) and I was very happy to see how well it worked interacting 32 bit and 64 bit geometry in my example code. It will actually solve a problem my users have had with incompatibility between regular 32 bit geometry and geometry that uses their own integer numerical type that overrides arithmetic operators to check for min and max int values which are "sticky" and model INF, -INF and NAN. My users will be happy with that change as well and it will be easy for my to convince them to adopt it. How can I advocate compile time parameters on the accessors to my users until you've first convinced me? Thanks, Luke