Switch statements and integer template values

Question

I am aware that if I instantiate a template such as:

template<int i>
int ReturnMeDouble()
{
    return 2 * i;
}

Then the compiler needs to be able to evaluate the value of i at compile time. My problem is (dumbed down for simplicity) that I want my program to call one of two functions depending on a variable. My code looks something like this:

int returnValue = 0;
switch(value)
{
    case 1:
    case 2:
    case 3:
    case 4:
        returnValue = ReturnMeDouble<value>();
        break;
    case 5:
    case 6:
        returnValue = ReturnMeTriple<value>();
        break;
}

The real ReturnMe... functions do something less trivial. Now obviously, I could use this switch statement and provide individual calls under each case statement, but I was just wondering if there was something I'm missing, since it seems obvious to me (if not to the compiler) that in the first case, ReturnMeDouble can only be called with one of four values.

Is it simply that the compiler would have to put in a conditional flow around the four separate function templates that would need instantiating (effectively what I'm trying to avoid doing manually) and it doesn't know how to?

Is there a more elegant way of doing this?

Edit: To clarify - the less trivial implementation uses the integer value to apply some metaprograms for type selection within the function.

Answer 1

I think you've pretty much nailed it with your attempted explanation.

The standardese way of looking at things is simply that the value you supply as a template argument must be a constant known at compile time. Since the value you've supplied is a variable that's not known until run-time, it's simply not allowed.

Yes, in this specific case, a compiler with a decent optimizer could probably figure out the four constant values that would need to be supplied for the four cases you've given.

There are quite a few more cases that are likely to be a lot less clear-cut though. For example, cases where a compiler that incorporates some specific optimization can figure out that a particular value is really a compile-time constant, but another lacking that particular optimization won't know it.

Faced with a question they couldn't answer ("can the compiler deduce this value at compile time?") the committee took a fairly conservative approach, and specified a relatively narrow range of allowable inputs. A compiler could, of course, choose to accept other expressions as an extension.

From the committee's viewpoint, I think adding constexpr was an attempt at a fairly general implementation of something at least fairly similar -- allowing a much larger range of computation to be done in a way that lets the compiler know a result should be available as a compile-time constant. Given the complexity of implementing even that, my guess is that mandating compile-time computation for cases like you've given above is unlikely (at least for the near future).