First, in real modern CPUs _practical_ differences are not that big. E.g., put the inlining limit to 32 bytes (for fast code) and you will hardly see performance degradation anywhere.

But the main issue: inlining often leads to code that is actually shorter than the call.

So do I. I have spent years optimizing stuff in C++. Benchmarking and examining produced assembly is my second nature. That is why I am pretty sure I could not achieve C++ levels in any other language, assembler included.

Specifically, in my C++ code, String comparison inlined fast path collapses to 5 assembler opcodes. That is about as long as function call.

And I would not call String comparison trivial accessor.

But even so, the problem of even trivial accessors is that they often tend to go deep. In container intense code, without inlines, you might end spending 50% of time just managing stack frames for element retrieval calls.

No dispute there, there is a big problem with C++ and maintaining shared library compatibility.

For most applications it can be easily solved by not using shared libraries... Facebook would be a nice example. After all, PHP does not produce .so libraries as well...

But that, as you correctly conlude, in C++ affects mainly switch statements or inter-shared library (or dll) calls and has little to do with inlines.

Anyway, if you want to be really fast, you could completely rewrite the whole thing and add huge data caches managed by C++, removing most of DB traffic in the process.

Only people still using manual memory management.

Is this some kind of joke? I would swap C++ for PHP anytime to actually GAIN possibility to express algorithms easily.

There is no such language where experienced programmer could do refined algorithm a well as in C++.

Yeah, app code might occupy a little bit more. Really big apps in C++ have say 20 MB compiled. So they would be only 15MB without extensive template use. Hardly any difference if your memory space is in gigabytes.

It is hard to make general statements about C++ and GUI. In some cases, like MFC, you are certainly true. Other like Qt are better. Some claim to outrun everything else in terms of both development costs and runtime performance:

http://www.ultimatepp.org/www$uppweb$vsswing$en-us.html

What a pity they are mainly written in C (GTK, Windows), Java (Android) and Objective C (MacOS X) then...

Correct, but it does not change the premise. Actually, all major C++ compilers are well aware about the situation and are very good at optimizing inlines (and not optimizing when it does not make sense).

In fact, what really counts is not inlining itself, but optimization across multiple functions call - in C++, multiple calls can get collapsed into a couple of assembly instructions. Often, such collapsing leads into less code bytes than required to perform function call.

BTW, branch prediction does not have anything to do with unconditional procedure calls. Branch prediction is about conditional jumps. That said, yes, modern CPUs are pretty good at about everything.

Seriously, if you take into account templates and inlining, there is a good chance that moderately good C++ code will run faster than moderately good assembly, on x86-64 of course - simply because assembler coder would not have the patience to take all opportunities of inlining.

Really?

See? Right here you say that artificially increasing prices of oil via carbon tax is OK, but if prices will go up because of economy (that happens if some resource becomes scarce), all sudden everything is wrong and we will have serious problems. Don't you see that carbon taxes will create exactly the same problem, this time possibly for some artificial reson?

The most trivial solution to every problem is always death, of course.

Interestingly, all you need to limit the immortal population is to allow a maximum of two children per parents (or maximum one child per person).

Not that big deal IMO. China was able to do even better :)

Of course, there would still be much more people. We will still need to move out to the space.

OTOH, in most advanced countries we have a population decline. Immortality is one way to deal with the problem :)

That is in fact quite a long time. 91 years ago was the time of first cars, planes and electronics...

Also, thinking about it.... Does not "hibernation" technology also give you means to deal with growing population? Would not be bad if you get bored to hibernate until more interesting times. Putting to the extreme, you can hibernate large fraction of population until you develop technology to colonize the space :)