an "old beard" ?

Two of the problems you mention are caused because C++ is all about performance.  Any language
feature that will slow things down requires the programmer to explicitly use it.

Array new is a separate function because it has to store the number of elements in the memory
allocation.  Making new and array new the same would waste a size_t for every alloc.

Virtual has to be specified because it slows down the function calls.

I have personal recent experience with virtual.  I used virtual functions in an interface base
class.  After I got done profiling, I did explicit calls to class functions instead of
virtuals in the derived classes and one use of dynamic_cast and then using the pointers with a
template function.  The code was over 20 times faster.

The real killer wasn't the indirect jump, it was how virtuals block inlining and most compiler
optimization, since it can't know what function will really be called.

What the commenters above are expressing is simply fear of learning.  (Read a modern C++
program, and you won't find any calls to "new" or "delete", array or otherwise.  "Virtual"
isn't the default because it's only rarely the right thing. It's been years since I typed the
keyword "virtual" in my own C++ code.) If you don't chafe at the lack of expressiveness in C,
Java, or C#, it can only be because you're not trying to express much of anything.  Ian chose
C++ not just because he "prefers" it (whatever that means).  He chose it because it's
demonstrably better at expressing complex solutions to complex problems.  

For an easy problem, any old language will do.  Most problems are easy, and most programmers
spend their lives solving one easy problem after another.  They can use whatever toy language
they first encountered, and never learn another thing.  People drawn to hard problems want the
sharpest tool they can get.  Right now C++98 is that tool.  (C++09 will be a sharper tool.)
Nothing else even comes close, and nothing on the horizon looks like it will.  That's too bad,
because a language equally powerful but a tenth as complex ought to be possible, but none
seems to be forthcoming yet.

You all seem to be concentrating on the limbs of the trees I mentioned, ignoring the entire
forest.

I know perfectly well why C++ has all those warts, speed.  But languages progress by more than
merely adding hundreds of new steam gauges (to use a quaint hardware engineers' term) to an
engine to allow ever finer control of it.  Anyone who is familiar with radial engines, those
wonderful noisy big round engines on WW II planes, will understand my comparison of C as the
R2800 and C++ as the Wright 3350 (hope I got that "right") which was the complex culmination
of radial engine technology.  What was needed was not such a finicky beast but a new way of
thinking, the jet engine, especially augmented with a glass cockpit which only shows you those
instrument readings you need to know, such as only engine temps which are out of spec.

C++ is horrible because it added complexity without benefit.  It has all the hallmarks of
kluge piled on top of kluge, patched and held together by duct tape.  3 times as many malloc
call pairs and the additional trap of mixing them up?  I doubt C++ gained triple the benefit,
and to say that the compiler, even while knowing the types, could not choose the right calls
based on type, beggars the imagination.  I would be embarrassed to rely on such a sorry excuse
for an excuse.  If virtual should only be used when absolutely necessary, then it was designed
wrongly.

That is what I was complaining about, not the rationale for each additional complication.  All
these complicated additional features screamed loud and clear that the basic design was flawed
beyond redemption; it's too bad no one was brave enough to say the emperor's clothes were
darned to nothingness.  That is why C++ disgusts me and I avoid it like the plague.

I did read the article, and I agree that C++ doesn't inherently make his state transition
stuff harder to understand. But it also doesn't help. That's all. I guess there are languages
which would, but I don't know if they're also suitable for the low-down bit mangling the
linker does elsewhere.

Actually that appears to be the author arguing that his program runs faster in part because it
avoids byte swapping on the native architecture, a trivial optimisation which he's managed to
manufacture into some C++ templates. In practice, looking at the sample code, templates seem
to deliver about the same maintainability as endian-swap macros, which is what an equivalent C
program (not the existing GNU ld) would use. I don't see a claim that it was actually /easier/
than macros, do you? Just that this optimisation is worth having, despite the complexity
compared to GNU ld.

Keep in mind I used to write my own programs in C++, and I stopped, so I'm not arguing from
ignorance or out of some misguided attempt to avoid learning something new. I made an explicit
choice to stop, and I think my choice was justified. At the time a lot of people told me it
was a mistake, but some of them have since stopped too.

But I don't want to waste my whole week arguing with language fanatics of any stripe. Code is
king, and anyway the main consumer for a faster linker is huge C++ programs, and this faster
linker is written in C++, so that should mean the people who care are already in a position to
look after it. Good luck, and if gold becomes the default please don't break the trivial cases
needed for linking my C programs.