Question

what should be the behavior in the following case:

class C {
    boost::mutex mutex_;
    std::map<...> data_;
};

C& get() {
    static C c;
    return c;
}

int main() {
    get(); // is compiler free to optimize out the call? 
    ....
}

is compiler allowed to optimize out the call to get()?

the idea was to touch static variable to initialize it before multithreaded operations needed it

is this a better option?:

C& get() {
    static C *c = new C();
    return *c;
}

Answer 1

Updated (2023) Answer:

In C++23 (N4950) any side effects of initializing a static local variable are observable as its containing block is entered. As such, unless the compiler can determine that initializing the variable has no visible side effects, it will have to generate code for to call get() at the appropriate time (or to execute an inlined version of get(), as the case may be).

Contrary to earlier standards, C++ 23 no longer gives permission for dynamic initialization of a static local variable to be done "early" (as discussed below).

[stmt.dcl]/3:

Dynamic initialization of a block variable with static storage duration (6.7.5.2) or thread storage duration
(6.7.5.3) is performed the first time control passes through its declaration; such a variable is considered
initialized upon the completion of its initialization.

Original (2010) answer:

The C and C++ standards operate under a rather simple principle generally known as the "as-if rule" — basically, that the compiler is free to do almost anything as long as no conforming code can discern the difference between what it did and what was officially required.

I don’t see a way for conforming code to discern whether get was actually called in this case, so it looks to me like it’s free to optimize it out.

At least as recently as N4296, the standard contained explicit permission to do early initialization of static local variables:

Constant initialization (3.6.2) of a
block-scope entity with static storage duration, if applicable, is performed before its block is first entered.
An implementation is permitted to perform early initialization of other block-scope variables with static or
thread storage duration under the same conditions that an implementation is permitted to statically initialize
a variable with static or thread storage duration in namespace scope (3.6.2). Otherwise such a variable is
initialized the first time control passes through its declaration; such a variable is considered initialized upon
the completion of its initialization.

So, under this rule, initialization of the local variable could happen arbitrarily early in execution, so even if it has visible side effects, they’re allowed to happen before any code that attempts to observed them. As such, you aren’t guaranteed to see them, so optimizing it out is allowed.