2

Huh it's getting so muddy.The following IBM Support Portal link seems to suggest that the reason we can't use const qualified variables as real constants is because their life-time is not the same as that of the program itself.It seems to say that only about local variables as global variables have the same lifetime as the program. (IBMLINK).Here's what exactly it says :

An object that is declared const is guaranteed to remain constant for its lifetime, not throughout the entire execution of the program. For this reason, a const object cannot be used in constant expressions.

But in the following program,since the lifetime of the const qualified variable is the same as that of the execution of the program, why I still get the error when I use it after case in the switch-case statement,where a constant is expected?It gives the following error:

|11|error: case label does not reduce to an integer constant|

#include<stdio.h>

const int x=2;

int main(void)
{

switch(2)
{
    case 1:
    printf("Hello");
    break;
    case x:
    printf("Hola");
}

}
Jugni
  • 255
  • 5
  • 12
  • possible duplicate of [switch case: error: case label does not reduce to an integer constant](http://stackoverflow.com/questions/14069737/switch-case-error-case-label-does-not-reduce-to-an-integer-constant) – Shafik Yaghmour May 16 '13 at 13:37
  • [Related question](http://stackoverflow.com/questions/16235025/is-const-int-x-get-legal-in-ccan-we-assign-a-functions-return-value-to). – Lundin May 16 '13 at 14:02
  • clang supports this as an extension. – alk May 16 '13 at 17:35
  • `An object that is declared const is guaranteed to remain constant for its lifetime`. No, no. No, no, no. Just because a suit-wearing toolbox at IBM says this doesn't make it so. Always refer to the C standard, not some person's Sunday afternoon scrawlings, when you want the truth. Anyone who's worked in embedded systems will tell you there are plenty of cases where something is decalred const (specifically, "volatile const"), where the value **can** change. `const` means *you* can't change the value (well, your code), but it doesn't mean the object's value will never change. – Dan May 19 '13 at 19:34

3 Answers3

4

The reason C has strict restrictions on what can be used in a constant expression is to allow:

  1. Simple compiler implementations,
  2. Simple linker implementations, and
  3. Highly efficient code generation

For global const-qualified variables with internal linkage, allowing them in constant expressions would not be too costly. It need not impact items 2 and 3 above, just item 1. But in general (possibly external linkage), allowing them would mean:

  1. The compiler needs to leave an allowance (relocation of some sort) to resolve not just the address but the value at that address at link time. In general, this problem is as difficult as full program-at-once/link-time-optimization, which the standard does not require. In some special cases it might not need such a powerful solution.

  2. The linker must be able to handle evaluation of complex expressions based on relocations: not just address constants but values, and thereby, all expressions you can legally derive from those values.

  3. In the case of switch, the efficient implementations (jump table or binary tree of conditionals) are both ruled out if the compiler doesn't know the values of the case labels. This could be solved by moving all the work to link-time (program-at-once/LTO).

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • Don't you feel that that IBM link,in the quoted paragraph,seems to indirectly but misleadingly suggest that we can use `const` qualified variables in constant expressions if their lifetime is same as that of the program? – Jugni May 16 '13 at 13:46
  • Yes. That IBM documentation is nonsense. – R.. GitHub STOP HELPING ICE May 16 '13 at 13:49
  • 1
    Thanks for pointing that out.For lay-person like me,it's hard to think anything on a site like that could be wrong. – Jugni May 16 '13 at 13:56
  • Actually, it's more confusing than wrong. If you take the second sentence as the definitive one, it very much states that const objects are not allowed. The _reason_ (in the first sentence) may be a bit iffy, but that doesn't change the basic requirement that they're disallowed - see my answer for the standards document references. – paxdiablo May 17 '13 at 07:28
2

I think you're reading your own message into that quote.

An object that is declared const is guaranteed to remain constant for its lifetime, not throughout the entire execution of the program. For this reason, a const object cannot be used in constant expressions.

This is saying in the second sentence that no const objects are allowed in constant expressions, none at all.

The reason for it is given in the first sentence and, while we can envisage situations where it would be possible to use a const object that way, that in no way changes the definitive second sentence.

It's not that much different from a pre-school banning all dogs because the more aggressive ones might bite the children.

The C standard dictates this behaviour so it's not really something you should hold against IBM. Their documentation may be vague (in some readings) but they are doing the correct thing.

In (C99) 6.8.4.2 The switch statement /3, we see:

The expression of each case label shall be an integer constant expression and no two of the case constant expressions in the same switch statement shall have the same value after conversion.

And in 6.6 Constant expressions /6 of that same standard, it defines integer constant expression thus:

An integer constant expression shall have integer type and shall only have operands that are integer constants, enumeration constants, character constants, sizeof expressions whose results are integer constants, and floating constants that are the immediate operands of casts. Cast operators in an integer constant expression shall only convert arithmetic types to integer types, except as part of an operand to the sizeof operator.

As you can see, there's no mention of const variables there.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
0

The problem is that the value of x is not established until run time, but case label expressions (and non-VLA array dimensions) need to be known at compile time so that the compiler can generate the appropriate code. At compile time, all that the compiler knows about x is that it is an identifier and has integer type; it does not have a value associated with it.

John Bode
  • 119,563
  • 19
  • 122
  • 198
  • Umm...but how come value of x is not known to the compiler?We have clearly initialized it with 2,haven't we? – Jugni May 16 '13 at 14:19
  • And what you mean when you say `non-VLA array dimensions need to be known....`.After all there is no special declaration for non-VLA arrays,any array where we use a variable as an array size becomes a VLA,else it is non-VLA.Isn't it? – Jugni May 16 '13 at 14:22
  • @Jugni: In C, that value will not be established until run time. And yes, you're correct, if we use a variable for the array dimension *and* the compiler supports VLAs, it becomes a VLA. Just remember that VLAs cannot be `static` or used outside of a function. – John Bode May 16 '13 at 14:32
  • Before I end,tell me this much only,conclusively.Do you mean global value identifiers used in the main() program are not liked to their initialized values at compile time, but it is done only in runtime? – Jugni May 16 '13 at 14:50
  • @Jugni: Yes. Note that C++ is different in this respect; in C++, `const int x = 2;` would establish `x` as a compile-time constant. – John Bode May 20 '13 at 03:16
  • You mean `const int x=2;` declared and initialized at the global scope right?Just to be totally sure... – Jugni May 20 '13 at 05:46