I really love this product.

C++ seems to be constantly getting complicated. If the major version were to change, there wouldn't be any need for backward compatibility with the existing code, and it would have been okay to delete that syntax while creating an automatic formatter.

>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.

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

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.

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++...

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.

Then, what you're going to do is create a new programming language with Esperanto

Actually, the use of Hanza(Hanzi)-Hangul mixed script wasn't exactly a byproduct of the Japanese occupation. (In fact, Japanese was the official language back then lol)

People started moving away from using difficult-to-type Hanza as soon as the typewriter was introduced. As computerization progressed, the transition naturally continued until Hanza was phased out of most documents. Even so, it has only been about 40 years since Hanza disappeared from everyday daily life.

However, in the vast majority of cases, non-ASCII characters are rarely used for variable or function names during programming. This is because they can cause conflicts when using different encoding systems, and some automation tools fail to recognize them. Consequently, programmers in non-English speaking regions must invest more effort into naming variables than English speakers, as they have to translate all localized expressions into English.

When Toss, a Korean unicorn startup, announced that they would start using Korean for variable names within financial contexts, it sparked significant debate and a wide range of reactions among Korean programmers.

It's been a long time since I've seen a properly implemented Korean programming language