Are you suggesting we move to C++++?

It's already there. It's called C#

Well, C# also has its quirks already. Like the crippled finalizers which are never to be used. If the IDisposable interface had been correctly designed, finalizers could become be the "public void Dispose(void)". Or the manual passing of Task in case of async methods, which is... kinda smelly.

It's possible you didn't realise, but C# is sometimes said to be named that way because # is the symbol you get if you draw ++ small and then on the line below ++ again. Hence C++++

All languages have some spikier edges, there are no languages I know where I think "Well, even if we could start over I have no idea how to improve this". What's notable about C++ is just how rich that "could do better" seam is, so very many of their defaults are wrong, so many of their keywords are the wrong word, so many of their standard library features are allowed, sometimes even mandated to be crap.

I don’t know if that’s true or not, but while the thought never crossed my mind before your comment, it’s now canon in my mind. Yes, C# is spelled C++++ with a ligature.

The name is actually pretty clever (the fact that it was originally un-googlable notwithstanding). There are at least three interpretations:

* "C sharp" as in "C but higher",

* C with four pluses, and

* a homophone of "see sharp"

I think you meant to get that to the original poster, who seems to imply C# is the flawless, bestest incarnation of C\+\+(\+\+)+.

This is a fundamental problem with GC-ed languages. You can't get predictable finalization, so IDisposable can never be implemented reliably.

“#” is just two “+”. Count the lines.

Personally I like C+. Picking the nice parts of C++, but skipping all the nonsense. I just wish C++ hadn't deliberately screwed up designated initializers with mandatory ordering. The C version of it that allows out-of-order assignments is clearly superior.

Didn't you read the article? That form is deprecated. The recommended one is C,++,++

You clearly didn't read it either. Going forward, it will be C++...

>If the major version were to change, there wouldn't be any need for backward compatibility with the existing code,

I have no idea where you get this idea from. I expect gcc v28 to be able to compile C++ from 2008, and I'm not alone in that.

I completely agree with you.

That said, I wish code written for gcc v28 didn't have to be binary compatible with C++ that was last compiled in 2008...

It isn't.

And yet GCC and MSVC both refuse to break ABI and have done so for over a decade.

Some of us have been writing code for quite a bit longer than that.

The 2000's and C++ were a clusterfuck largely for this very reason.

I’ve been writing c++ since before then too. A lot has changed in the world, notably package managers are actually used with c++ these days.

MSVC used to break library ABI pretty much on every release. They stopped after overwhelming customer demand.

I mean this is extremely minor, but the more incompatibility you create the slower the uptake will be. In the extreme you could create a Python 2->3 situation over old syntax.