Boost logo

Boost :

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


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
algorithms that don't need to deal with dynamic variations of the index,
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

Boost list run by bdawes at, gregod at, cpdaniel at, john at