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

Improve this question
4
  • 2
    What makes you think registers have addresses? Commented Feb 14, 2011 at 20:12
  • 2
    const variable is an oxymoron Commented Feb 14, 2011 at 20:17
  • so they(register) are defined only with their respective names? Commented Feb 14, 2011 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. Commented Feb 14, 2011 at 20:44

5 Answers 5

Reset to default
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.

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

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"
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.
I would imagine most implementations put i on the stack by default, but can move it elsewhere during an optimization pass. See also: stackoverflow.com/questions/1576489/…
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.
@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.
|
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.

Improve this answer

Comments

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.

Improve this answer

Comments

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

Improve this answer

Comments

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.

Improve this answer

2 Comments

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 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! :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.