3

these are the some silly question ..i want to ask..please help me to comprehend it

const int i=100;   //1
///some code
long add=(long)&i;  //2

Doubt:for the above code..will compiler first go through the whole code
for deciding whether memory should be allocated or not..or first it ll store the
variable in read only memory place and then..allocate stroage as well at 2

doubt:why taking address of variable enforce compiler to store variable on memory..even
though rom or register too have address

user388338
  • 729
  • 2
  • 6
  • 11
  • 2
    What makes you think registers have addresses? – Frédéric Hamidi Feb 14 '11 at 20:12
  • 2
    const variable is an oxymoron – David Heffernan Feb 14 '11 at 20:17
  • so they(register) are defined only with their respective names? – user388338 Feb 14 '11 at 20:25
  • 2
    @user388338: You are thinking about specific hardware if you think register can or can not be addressed epciffically. Some hardware have registered that are represented by magic memory locations thus making them addressable while others do not. C++ compiles on a lot of hardware so the way you are thinking may not be applicable to all hardware. Line 2 just means the compiler must generate in a way that it has an address (mind you if you turn on high optimization the actual address may disappear completely (it all depends)). The main worry hear is that you are casting away the const-ness. – Martin York Feb 14 '11 at 20:44

5 Answers5

5

In your code example, add contains the address, not the value, of i. I believe you may have thought that i was not stored in normal memory unless/until you take its address. This is not the case.

const does not mean the value is stored in ROM. It is stored in normal memory (often the stack) just like any other variable. const means the compiler will go to some lengths to prevent you from modifying the value.

const is not, and was never intended, to be some sort of security mechanism. If you obtain the address of the memory and want to modify it, you can do so. Of course this is almost always a bad idea, but if you really need to do it, it is possible.

Nate
  • 18,752
  • 8
  • 48
  • 54
  • you are right on money with your perception of my problem but i read in bruce eckel "the c++ compiler avoids to create storage for const,instead holds the defination in symbol table" – user388338 Feb 14 '11 at 20:19
  • 1
    Actually we don't know where the memory for `i` is located: if the declaration is inside a function body then it is likely to be on the stack. If it is at file scope it will be elsewhere, and whether or not that means ROM is implementation-dependent. Any attempt to cast the value of `add` back to a pointer and use it to modify the contents of `i` will produce an undefined result. – wades Feb 14 '11 at 20:22
  • I would imagine most implementations put `i` on the stack by default, but can move it elsewhere during an optimization pass. See also: http://stackoverflow.com/questions/1576489/where-are-constant-variables-stored-in-c – Nate Feb 14 '11 at 20:26
  • actually i am confused b/w these two statements given in book .."in c++ compiler avoiding storage for const"...."in c a const always occupy storage" – user388338 Feb 14 '11 at 20:36
  • 1
    It's actually undefined behavior to change a variable that is fundamentally `const` . Note that this is *different* from casting away a `const` that was added for example by passing via `const&` as a function parameter. – Mark B Feb 14 '11 at 20:45
  • @user388338: You are right that Eckel says: “Normally, the C++ compiler avoids creating storage for a `const`, but instead holds the definition in its symbol table. When you use `extern` with `const`, however, you force storage to be allocated (this is also true for certain other cases, such as taking the address of a `const`).” I bet a lot of compilers do this, but it is still an implementation detail or optimization. From the programmer’s perspective a `const` should be like any other variable except the compiler prevents you from modifying its value. – Nate Feb 14 '11 at 21:20
  • As always the only way to find out what actually happens is to look at the output of compiling your code on your platform on your compiler… – Nate Feb 14 '11 at 21:21
  • 1
    @Nate: I have found that on compilers for embedded systems, `const` data is either placed into ROM or the executable. Some compilers may *copy* the data from ROM to the *stack*. If the keyword `static` is used, compiler access the data directly from ROM without copying. This was shown in the assembly language. – Thomas Matthews Feb 14 '11 at 21:56
1

I never wrote a compiler implementing this, but I think that it would be simple to just handle the variable as a normal variable but using the constant value where the variable value is used and using the address of the variable if the address is used.

If at the end of the scope of the variable no one took the address then I can just drop it instead of doing a real allocation because for all other uses the constant value has been used instead of compiling a variable loading operation.

6502
  • 112,025
  • 15
  • 165
  • 265
1

constant values (not the only use for const, but the one used here) are not 'stored in normal memory' (nor in ROM, of course). the compiler simply uses the value (100 in this case) whenever the code uses the variable.

Of course, if the value isn't stored anywhere, there's no meaning of an address for the constant.

Other uses of const are stored in 'normal memory', and you can take their address, but the result is a 'pointer to const value', so it's (in principle) unusable for modification of the value. A hard cast would of course change that, so they trigger a nasty compiler warning.

also, remember that the C/C++ compiler operates totally at compile time (by definition!), it's nothing unusual that some use at a later part affects the code generation of an early part.

A very obvious example is the declaration of stack variables: the compiler has to take into account all the variables declared at any given level to be able to generate the stack allocation at the block entry.

Javier
  • 60,510
  • 8
  • 78
  • 126
0

I am a little confused about what you are asking but looking at your code:

i = 100 with a address of 0x?????????????

add = whatever the address is stored as a long int

Tbone
  • 129
  • 1
  • 9
0

There is no (dynamic) memory allocation in this code. The two local variables are created on stack. The address of i is taken and brutally cast into long, which is then assigned to the second variable.

Gene Bushuyev
  • 5,512
  • 20
  • 19
  • Nice adjective `brutally`. If you can go into more detail about why brutally casting something is a bad idea you can get my +1 – Martin York Feb 14 '11 at 20:37
  • @Martin I will try to help here :-). Using a C style cast to turn a 'const int*' into a 'long' is not only a problem with the const-ness, but also we don't know if the result even fits into a long. Pretty brutal to me! :-) – Bo Persson Feb 14 '11 at 21:35