Boost logo

Boost :

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-02 17:40:33


s J
> <lucanus.j.simonson_at_[hidden]> wrote:
> >
> > We both have the same intent of improving programming practices
through
> > library development. The way people code geometry typically looks
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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk