C++: Calling a constructor to a temporary object

Question

Suppose I have the following:

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

Without optimization, the SomeClass() constructor will be calle

Answer 1

However, according to an IRC channel that constructor/destructor call may be optimized away if the compiler thinks there's no side effect to the SomeClass constructors/destructors.

The bolded part is wrong. That should be: knows there is no observable behaviour

E.g. from § 1.9 of the latest standard (there are more relevant quotes):

A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible executions of the corresponding instance of the abstract machine with the same program and the same input. However, if any such execution contains an undefined operation, this International Standard places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation).

As a matter of fact, this whole mechanism underpins the sinlge most ubiquitous C++ language idiom: Resource Acquisition Is Initialization

Backgrounder

Having the compiler optimize away the trivial case-constructors is extremely helpful. It is what allows iterators to compile down to exactly the same performance code as using raw pointer/indexers.

It is also what allows a function object to compile down to the exact same code as inlining the function body.

It is what makes C++11 lambdas perfectly optimal for simple use cases:

factorial = std::accumulate(begin, end, [] (int a,int b) { return a*b; });

The lambda compiles down to a functor object similar to

struct lambda_1
{
     int operator()(int a, int b) const 
     { return a*b; }
};

The compiler sees that the constructor/destructor can be elided and the function body get's inlined. The end result is optimal ¹

---

More (un)observable behaviour

The standard contains a very entertaining example to the contrary, to spark your imagination.

§ 20.7.2.2.3

[ Note: The use count updates caused by the temporary object construction and destruction are not observable side effects, so the implementation may meet the effects (and the implied guarantees) via different means, without creating a temporary. In particular, in the example:

shared_ptr<int> p(new int);
shared_ptr<void> q(p);
p = p;
q = p;

both assignments may be no-ops. —end note ]

IOW: Don't underestimate the power of optimizing compilers. This in no way means that language guarantees are to be thrown out of the window!

¹ Though there could be faster algorithms to get a factorial, depending on the problem domain :)

Answer 2

I'm sure is 'SomeClass::SomeClass()' is not implemented as 'inline', the compiler has no way of knowing that the constructor/destructor has no side effects, and it will call the constructor/destructor always.

Answer 3

If the compiler is optimizing away a visible effect of the constructor/destructor call, it is buggy. If it has no visible effect, then you shouldn't notice it anyway.

However let's assume that somehow your constructor or destructor does have a visible effect (so construction and subsequent destruction of that object isn't effectively a no-op) in such a way that the compiler could legitimately think it wouldn't (not that I can think of such a situation, but then, it might be just a lack of imagination on my side). Then any of the following strategies should work:

• Make sure that the compiler cannot see the definition of the constructor and/or destructor. If the compiler doesn't know what the constructor/destructor does, it cannot assume it does not have an effect. Note, however, that this also disables inlining. If your compiler does not do cross-module optimization, just putting the constructor/destructor into a different file should suffice.

• Make sure that your constructor/destructor actually does have observable behaviour, e.g. through use of volatile variables (every read or write of a volatile variable is considered observable behaviour in C++).

However let me stress again that it's very unlikely that you have to do anything, unless your compiler is horribly buggy (in which case I'd strongly advice you to change the compiler :-)).