[pmr_]

That is the kind of magic thinking of C++ programmers sometimes exhibit that drives me insane.

Yes, compilers have become excellent at optimizing code, but they aren't magical. The generated code will have some semblance to the code we write. Eliding dynamic allocations is just not possible statically. Heck, we aren't even able to emit warnings for missing deallocations reliably and have to use run-time instrumentation for it.

Even in C++ or C, even with good compilers, we still have to go the extra mile if we want fast code.

[twoodfin]

That is the kind of magic thinking of C++ programmers sometimes exhibit that drives me insane.

I dunno. I've run into too many programmers on the other end of the spectrum. They're reluctant to take advantage of the genuinely zero-cost abstractions that today's excellent optimizing compilers for C++ enable.

I can't find the reference now, but I thought I had seen some discussions at one of the ISO C++ meetings (from Google?) about potential standards changes to allow allocations to be elided when they're limited to some known scope.

[vardump]

> I dunno. I've run into too many programmers on the other end of the spectrum. They're reluctant to take advantage of the genuinely zero-cost abstractions that today's excellent optimizing compilers for C++ enable.

Performance wise it might give a false impression of being zero-cost if you micro-benchmark or are very selective what you consider as a cost. Handy for developer effort wise, sure.

Yes, it's often cheap or even 'zero-cost'. But you can't assume that to be always the case.

In an actual system it might be not so zero-cost when there are multiple concrete instances of generated code of the template. Each consume require actual generated machine code. Larger code size can have a significant performance cost. TLB and L1C cache misses are far from free. Neither is loading the larger executable for short life time processes. Extra page fault, caused by larger memory requirements, that goes all the way to disk is also rather expensive.

The whole picture is simply way too complicated to make blanket statements like that.

[blt]

I think the right approach is to get a decent high level understanding of how compilers work. Some surprising optimizations and failures to optimize become a lot clearer. For example, SSA makes it obvious why there's absolutely no penalty for using lots of named temporary register-sized variables.

Then learn your particular compilers' abilities by research and reading your assembly output. If you're depending on an optimization, always read the output. You might be pleasantly surprised as often as you're disappointed.

Understanding the rules of the language are important too. In C++, pointer aliasing and the worthlessness of 'const' are huge obstacles to some seemingly easy optimizations.

[pbsd]

You probably mean N3664 [1]. The compiler is indeed allowed to get rid of allocations in new expressions it deems unnecessary.

You can verify that recent versions of clang allocate no memory in the function

    int f() { return *new int(123); }

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n366...

[mappu]

Devirtualization for example.