Re: [boost] GTL compile time vs. run time accessors

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-05-02 18:25:44

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