views:

362

answers:

4

Could someone please explain the difference in how the 2 snippets of code are handled below? They definitely compile to different assembly code, but I'm trying to understand how the code might act differently. I understand that string literals are thrown into read only memory and are effectively static, but how does that differ from the explicit static below?

struct Obj1
{
    void Foo()
    {
        const char* str( "hello" );
    }
};

and

struct Obj2
{
    void Foo()
    {
        static const char* str( "hello" );
    }
};
+4  A: 

A local static variable is initialized the first time its definition is encountered, but not destructed when the function exits. So it keeps its value between invocations of the function.

In case of a const this is not all that helpful - at least, as long as constructing the constant value is as neglectable performance-wise as the assignment of an address. (If the const object is not a constant expression, and the expression takes considerable resources to create - like in const Foo bar = foobar();, where foobar() can take considerable time -, the difference might become important.)

Where it does make a difference is when you want to return the object per reference or pointer: You cannot return a reference or pointer to a local object, unless it is a local static object. (Thanks to Matthieu for pointing this out.) However, when you want to use this you need to keep in mind that local statics are inherently thread-unsafe.

sbi
I think you should underline the difference in lifetime, you can return a reference/pointer to the local static, but it's undefined to do it with a classic stack variable.
Matthieu M.
@Matthieu: You're right, I hadn't thought of that. Thank you, I'll add that to my answer.
sbi
And I'm glad you added the "threading" issue bit :) People often forget that local static variables are akin to globals and suffer from all their woes.
Matthieu M.
+1  A: 

While there is a technical difference, in terms of usage and effect your two examples are identical.

In more detail, your use of the static keyword applies to the pointer to the string literal, not to the string literal itself. The pointer in example 1 will be placed on the stack, the pointer in example two will be placed with the static variables.

I'd be suprised tif they don't both get optimized to the same thing though.

Joe Gauterin
+12  A: 

With your static version there will be only one variable which will be stored somewhere and whenever the function is executed the exact same variable will be used. Even for recursive calls.

The non-static version will be stored on the stack for every function call, and destroyed after each.

Now your example is a bit complicated in regards to what the compiler actually does so let's look at a simpler case first:

void foo() {
    static long i = 4;
    --i;
    printf("%l\n", i);
}

And then a main something like this:

int main() {
    foo();
    foo();
    return 0;
}

will print

3
2

whereas with

void foo() {
    long i = 4;
    --i;
    printf("%l\n", i);
}

it will print

3
3

Now with your example you have a const, so the value can't be changed so the compiler might play some tricks, while it often has no effect on the code generated, but helps the compiler to detect mistakes. And then you have a pointer, and mind that the static has effects on the pointer itself, not on the value it points to. So the string "hello" from your example will most likely be placed in the .data segment of your binary, and just once and live as long as the program lives,independent from the static thing .

johannes
A: 

I have found out that some compilers treat the two differently.

The version with const char * will copy data from a read-only location to a variable on the stack.

The version with static const char * references the data in the read-only location (no copy is performed).

I discovered this difference while stepping through the assembly code of a function, using the debugger. I suggest you either print out the assembly code or step through, at the assembly language level, with a debugger to find the exact truth.

Thomas Matthews