C++ at the End of 2022

https://www.cppstories.com/2022/cpp-status-2022/

by signa11 • 4 years ago

114 210 4 years ago

The most exciting news about C++ would not be added features, but removed features. That is what everyone in their heart is waiting for.

jeffreyrogers• 4 years ago

I'm glad C++ has added more features, it is a much nicer language than it used to be. string_view from C++17 is very convenient and just this past week I had to use std::latch from C++20.

witx2• 4 years ago

Yes, but the problem in my view is that for each of those small things we find useful they introduce tons of other features no one needs ...

usefulcat2• 4 years ago

The only problem being that “everyone” can’t agree on which particular set of features should be removed. Breaking existing code is always going to be a tough sell, for hopefully obvious reasons.

Brybry• 4 years ago

Would code need to be broken? I thought it was normal to deprecate features and then have the compiler throw a warning.

FpUser• 4 years ago

"That is what everyone in their heart is waiting for."

Nope. Not waiting for that. Does not mean I am using or ever will every feature. However if it exists and being used by others I have nothing against it.

nine_k• 4 years ago

Operator delete still exists. Dereferencing void * still exists. Access like a[i] is still unchecked. Etc.

But indeed, these things can't be removed or reworked without breaking backwards compatibility. (And if you seriously take on reworking them, you'll end up with a different language, which we already have several.)

pjmlp15• 4 years ago

Even Go gets to add features.

omoikane• 4 years ago

One major selling point of C++ over other languages is vast volume of the existing C++ code. If some critical portion of which required major updates to cope with the removed features, that might not be something that everyone is looking forward to.

I am just worried that some proponents of "move fast and break things" might be undervaluing what they are breaking, although C++ committees are are generally good about backward compatibility.

29athrowaway5• 4 years ago

They should simply kill the compatibility and provide a migration tool. clang-tidy provides the modernize module which can help.

If the only side effect of breaking backwards compatibility is making the people that write C++ as if it was C89 irritated and upset, then that's probably a good thing, let's do it more.

C++11 is 11 years old. If you haven't modernized your code base in 11 years you never will.

If you are using ancient C++, compiler security updates are the least of your security concerns.

If you have code that nobody understands and cannot be touched, you should see that as the real problem and an urgent call to action to fix it, not modernization.

jcelerier10• 4 years ago

no, i really want reflection and better code generation features for instance ; this would allow me to simplify and remove a lot of useless code. likewise, "deducing this" which made it into C++23 is likely going to allow me to remove at least a few hundred and hopefully a few thousand lines of the codebase I'm working on. And all this means less chances for bugs and more time actually writing features.

still_grokking43• 4 years ago

i really want reflection and better code generation features for instance

I know this won't be applicable in many cases regarding C++ projects, but if you want to see state-of-the-art code gen features in action have a look at Scala 3:

https://docs.scala-lang.org/scala3/reference/metaprogramming...

With something like that in place you actually don't need any (runtime) reflection (which is also available on the JVM OOTB, just in case).

darknavi• 4 years ago

Maybe I am behind in the times but it was a little surprising to me to see MSVC have full C++20 support while GCC and Clang are still trying to get there.

delta_p_delta_x• 4 years ago

Has been the case for the past half decade, too.

MSVC's stdlib has been open-sourced, and MSVC is used by plenty of companies writing games, native Windows software, etc.

mmozeiko• 4 years ago

Not fully open-sourced. There are bunch of pieces that are available only in compiled form - .obj/lib files. Like math.h functions.

elabajaba• 4 years ago

Afaik Clang development has massively slowed down since Google gave up on trying to improve C++ as a language (it required breaking ABI, which the C++ standards committee rejected). They moved on and created Carbon instead for future C++ development where they need to work with existing C++ code, and recommend Rust for greenfield development.

nindalf5• 4 years ago

Was clang development so dependent on one organisation? I can easily believe that many Google engineers are choosing to spend their time on Carbon now, but it seems strange that there was so much dependence here. Could there be some other reason for clang lagging behind?

Dylan168072• 4 years ago

From what I am aware of, google wanted to break API significantly, not just ABI, by changing a bunch of standard library guarantees.

joatmon-snoo2• 4 years ago

Far more likely to me is that bringing libc++ up to C++20 standards isn't important for google3. Carbon is a O(10y) project, not a O(3y) project.

  * absl strings provides the same compile-time guarantees that <format> does
  * absl date/time libs have integrations with the proto time types
  * google3 has many threading & synchronization primitives that it prefers over the STL types (all of which already has integrations with fleet-wide performance monitoring and other toolchain customizations, e.g. deadlock detection), so there isn't much reason to move the threading libraries forward

Shinmon4• 4 years ago

Microsoft does a pretty good job there. clang has been lacking behind ever since google reallocated resources somewhere else.

What bothers me most about C++ is that it's mostly old people now. All the young people who are actively involved in language design, tool development, ... are putting their effort into other languages.

pjmlp15• 4 years ago

There are young people still specially those wanting to work in cool domains like game development, however many older ones have some vested interests in keeping C++ the way it is, hence why even advocating for security is such an uphill battle.

Or see how WinDev is so resistent to change, instead of providing .NET like tooling for C++, like Borland/Embarcadero have done for the last 25 years, they stick to their ways of manually editing IDL files and COM.

still_grokking43• 4 years ago

What's wrong about old people?

The problem are people that don't want to change anymore. But this trait is independent form age in my experience.

But nevertheless, that C++ doesn't attract new developers may have reasons indeed. C++ refuses to get substantially modernized. In the long run such a stance will attract less and less people I think.

C++ would need a fresh start without all the baggage collected through several decades of backwards compatibility. A C++v2 is overdue, imho.

Only then it would find itself eventually competing with other new languages, without the current killer feature that reads "we can run ancient code". I'm not sure most people behind C++ are keen on such a challenge.

mempko2• 4 years ago

If you rephrase it, kind of sounds bad. What bothers you about C++ is that it's mostly experienced people now?

pjmlp15• 4 years ago

It is not surprising given the licenses, that the two major clang contributors decided to focus elsewhere (Swift, Objective-C and Carbon), while everyone else[0] is happilly just consuming clang, and only contributing to LLVM.

At least GCC has Red-Hat supporting ISO C++ improvements.

[0] - ARM, Intel, Embarcadero, IBM, NVidia, IBM, Nintendo, Sony,...

still_grokking43• 4 years ago

But Red Hat is IBM, nowadays.

Also AFAIK IBM is one of the most dedicated supporters of C++ in general.

jocaal• 4 years ago

You forgot to mention IBM

pjmlp15• 4 years ago

As noted on my Reddit comment, the low numbers on static analysis and sanitizers adoption are a bit sad, and shows the reality versus the typical comment that everyone is already using them.

DrBazza3• 4 years ago

Low numbers in the 649 people that found and answered that survey, and are in the intersection of "people that answer online surveys" and "probably aren't beginners at C++".

It would of course be helpful if all the many, many, many, build systems for C++ have 'integrating sanitizers' in their "hello world" tutorials, rather than buried in some arcane man page.

pjmlp15• 4 years ago

That is why it was so relevant that clang introduced static analysis as part of the compiler, instead of having to get hold of lint.

However it isn't for it being there (VC++ can even do analysis per build), that people are rushing to adopt them after all these decades (lint was born in 1979).

So the social aspect matters a lot, and we keep losing there.

JonChesterfield2• 4 years ago

Static analysis I strongly associate with wasting my time.

Valgrind on the other hand, I struggle to imagine writing working C++ without it.

saboot• 4 years ago

ctrl+f "reflection" no results found.

maybe next year ..

pjmlp15• 4 years ago

With luck, maybe after C++26, if at all.

suby• 4 years ago

There is something very wrong if they don't have reflection in 26. It is sorely needed.

sakesun• 4 years ago

Try C++ Builder

okamiueru• 4 years ago

Maybe not relevant to your interests, but I found this very interesting on the topic https://www.youtube.com/watch?v=aJt2POa9oCM

A case of "brilliant coder wants to make game but don't know art well, so they create new complicated programming tasks instead", but, the brilliant coder part is still pretty relevant.

still_grokking43• 4 years ago

What do they aim for? Runtime reflection? That's something that's indeed not very important. At least as long as you've got some form of "compile time reflection". But OK, C++ does not have either. (You could build something for sure, templates are Turing complete, but I'm not sure I would even like to see the result; could be very scary…)

maccard• 4 years ago

That's something that's indeed not very important

To you. Meanwhile many of us who do need it are stuck with buggy half implemented code generation tools.

joebaf• 4 years ago

is ChatGPT actually the most important thing that happens... not just for C++, but in terms of all programming languages? How will it affect programming?

klodolph• 4 years ago

I’ve seen ChatGPT spit out both correct and incorrect code.

The idea that you’d rely more on tools is in a sense the Java approach. Java is somewhat more verbose than other languages, in practice, and you deal with the verbosity by making more use of code snippets / templates, autocompletion, etc. Basically, your IDE writes more of the code for you. I think this was, in general, a dead end in language research for various reasons, and improving code generation (via ChatGPT or some successor) does nothing to solve the actual problems with using generated code.

At the end of the day, somebody has to at least read the code and verify that it does what is requested.

Maybe at some point, someone will hook a more formal front-end to ChatGPT or something similar, so you can write the interfaces and specs, and the AI will generate the implementation. That may take a while, however.

still_grokking43• 4 years ago

Basically, your IDE writes more of the code for you. I think this was, in general, a dead end in language research for various reasons, […]

I think language researchers would strongly disagree.

Something like that is likely the future of programming!

For example:

https://www.youtube.com/watch?v=X36ye-1x_HQ

From the video description:

In Idris, types are a first class language construct, meaning that they can be manipulated and computed like any other language construct. It encourages a type-driven style of development, in which programmers give types first and use interactive editing tools to derive programs.

McP• 4 years ago

I tried using GPT to write code and it was very impressive but this cartoon cuts to the truth of it: https://www.reddit.com/r/ProgrammerHumor/comments/zdvpwb/how...

roca• 4 years ago

I think the most interesting thing about C++ in 2022 is that big C++ names at Google are saying in public that if you can use Rust instead of C++, you should. https://github.com/carbon-language/carbon-lang/blob/trunk/do...

nindalf5• 4 years ago

The context behind this endorsement is that senior engineers at Google are unhappy with the decisions taken by the C++ committee. The big one is described in this document - What is ABI, and What Should WG21 Do About It? (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p20...).

The document ends with “I call on WG21 to make a conscious and explicit choice here, with the clear awareness that status quo is an endorsement of indefinite ABI stability. If we wish to be the systems language known for performance, we have to act now. If not, we have to be aware that we are giving up on some important user bases.”

The committee chose an endorsement of indefinite ABI stability. A defensible technical choice, certainly. However, not one that works for Google.

That explains why they’re going ahead with the development of Carbon, as well as their endorsement of Rust. They don’t think the future of C++ development at Google is bright.

This has other effects too. Someone in this thread pointed out clang is lagging behind in implementing C++20 compared to MSVC and GCC. This might be because Google is committing fewer resources to the maintenance and improvement of clang.

Further reading: Difficulties improving C++ (https://github.com/carbon-language/carbon-lang/blob/trunk/do...)

fxtentacle3• 4 years ago

My personal opinion on the whole thing is that the decision to not standardize the ABI was correct, because it has been easy since forever to define a static binary interface, if you (the developer) choose to do so. See OpenGL, for example.

If the compiler randomizes the ABI of stuff that you didn't explicitly export as an interface, that shouldn't bother anyone. Unless, of course, you're using undocumented APIs. And even then, you can solve all those issues by statically linking against your dependencies.

In 20+ years of building distributed C++ systems I've just never seen inter-compiler ABI compatibility being an issue in practice.

sseagull2• 4 years ago

There was a bit of discussion yesterday about 'immaturity' in the programming community. To me, this is an example of a broader immaturity.

Mature people/organizations are willing to give up their local minimum for greater good of the community (global minimum). This would include staying with a language where the standards don't always go your way.

Immature people/organizations say "I'm going to create my own language! With blackjack and hookers!". And the programming landscape fragments further...

UncleMeat6• 4 years ago

The committee chose an endorsement of indefinite ABI stability.

It actually didn't. It chose to further delay an actual decision here. The effect is almost the same but it means different things when it comes to understanding how the committee thinks and whether they largely agree or not.

codehalo• 4 years ago

They said the same thing for Java, Kotlin, and Go:

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

otabdeveloper4• 4 years ago

Google isn't some grand authority. It's an old, tired and dysfunctional legacy IT company, like IBM or Oracle.

smt883• 4 years ago

They aren't a grand authority, but they maintain a huge amount of C++ code

CoastalCoder4• 4 years ago

Google isn't some grand authority.

Agreed, but collaborative efforts like C++ language steering, Clang development, etc. can benefit from a large pool of contributors.

So IMHO, Google reducing investmentin Clang could be a net loss for most Clang users.

echelon3• 4 years ago

As a Rust developer [1], I can't help but look at C++ as anything but a very dangerous Perl that has outlived its welcome.

C++ can do all kinds of wacky stuff, all of which feels bolted on as the language tried to grow support for each passing paradigm and fad. The syntax is arcane and makes PHP look downright delectable. Pointer sigil placement and const correctness (dangerously) matters, template compile errors look like alien machine code, and no amount of new best practices will save you from old C++ codebases.

I can't see new people reaching to learn C++. It will die with its current users. It's difficult to learn anyway, mostly because the materials and community are inaccessible and stuck in the 90's. And the important lessons on how to actually properly do memory management aren't enforced and only come from painful failures, direct tutelage, or reading an entire book on the subject twice over.

If all Rust had going for it was Cargo, an improved syntax, and the better docs and compiler messages, it would still win. Thankfully it's got so much more than that, and it fixes many of the systemic problems that C/C++ can't address.

[1] (in production, generating revenue)

j1elo2• 4 years ago

I can't see new people reaching to learn C++

I guess you wrote this while knowing very well that it's just whishful thinking. People will keep learning C++ for the foreseeable future, in order to reach the job market that this language opens up.

And if "people" in this sentence meant the companies using it, then again not a chance in the short term. Most companies using C++ have huge codebases that will only be ported to something different when it makes financial sense for them to do it (which is something that almost never happens for an already existing codebase)

still_grokking43• 4 years ago

no amount of new best practices will save you from old C++ codebases

That's true.

But at some point maintaining this code will give you your weight in gold on a daily basis. Like it's currently for COBOL.

No, I'm not looking for such a job. I fear C++ and especially the legacy code. But there will be likely people willing to look after this code.

I can't see new people reaching to learn C++. It will die with its current users.

Successful languages don't "die". They fade out. Very, very slowly…

I think this process in some way resembles nuclear decay and the concept of half-time.

If all Rust had going for it was Cargo, an improved syntax, and the better docs and compiler messages, it would still win.

Well, yes, but the syntax is no real improvement. Rust is as ugly as hell. (Which does not say anything about the actual language as such. Syntax is "just syntax". But Rust has chosen deliberately an ugly syntax to attract C/C++ people, I guess).

flohofwoe• 4 years ago

The funny thing is, to somebody who's neither involved too much in C++ nor Rust, Rust syntax looks just as arcane as C++ ;)

blub3• 4 years ago

Are you writing this because it’s really interesting or because you’re a Rust promoter? Sneaking in comments about Rust in discussions about other languages is a classic guerrilla marketing move that the Rust community is known for.

Assuming the best intentions, one should think how misguided it is to look up to amoral entities like corporations as role-models. At a macro level, Google does what brings them money. At a micro level what brings the engineers promotions and improves their reputation.

tialaramex4• 4 years ago

Rather than about Google, which is just a corporation albeit a large one, this is about the direction of C++.

I've written about this before, there's a tendency to insist that if you just asked surely future C++ can accommodate whatever it is that is needed. What a bunch of people (many but not all from Google) did was write a C++ Proposal which says "This is what C++ needs" and the committee said "No". P2137 "Goals and Priorities for C++"

That finally means you can have the next conversation, instead of "Surely C++ can do that" we can get to "OK, C++ won't do that - what are we going to do instead ?"

The answers include a lot more Rust, as you have seen from Google and other entities.

I'm presumably part of the "guerilla marketing" you're talking about, although I don't think it's useful to imagine a community as engaging in "guerilla marketing" when they do what people naturally do, communicate. When people whose first language is Spanish speak Spanish to each other on the bus and you overhear them, that's not "guerilla marketing" for Spanish by any useful definition.

Here's the thing: If you think of this point as "guerilla marketing" then C++ has been riddled with "guerilla marketing" for Rust for several years. Vittorio's (failed) Epochs proposal for C++ 20 more or less just says "Look, Rust has this cool feature [Editions], we should do that too".

alphanullmeric2• 4 years ago

Even more interesting that rust has such an obnoxious showing in forum comments and GitHub surveys but little actual corporate adoption. Seems like nobody with actual money on the line wants to take the hit to productivity to fully switch to rust. Google is literally writing a whole new language instead of using rust and rustaceans are still trying to spin it as a pro rust move. And that’s after Go, which funnily enough has also seen way more industry usage than rust. Hobbyist language.

pjmlp15• 4 years ago

AWS serveless runs on a type 1 hypervisor written in Rust.

Google is using Rust on Android and Fuchsia.

Carbon is for C++ code that they can't write from scratch in Rust, given its size.

Azure Sphere SDK only supports C and Rust is now in preview mode. No C++ support planned.

So while it is decades away from reaching C++ adoption level, it isn't as if the big names aren't making use of it on key projects.

zozbot2343• 4 years ago

Little corporate adoption? Rust is most viable for pure greenfield projects, which are rare, or gradual conversions from pure C most of which is now on weird embedded chips where Rust is inherently at a disadvantage for all sorts of reasons. When you account for that, Rust adoption is actually happening very rapidly. There's even a lot of RIIR activity that wouldn hardly be expected for any other language.

bowsamic• 4 years ago

Steve is gonna subtweet you so hard for this!

unrealhoang• 4 years ago

Google has just literally put 1.5M lines of Rust code inside their Android runtime and reaping the benefits [0]. Is that pro Rust enough?. Sure not every project can migrate easily and they need to have a matching semantic language, that said, Carbon is still way (3-5 years) too early to be practical.

[0] https://security.googleblog.com/2022/12/memory-safe-language...

DrBazza3• 4 years ago

Also, https://www.val-lang.dev/ seems more interesting. And http://www.jot.fm/issues/issue_2022_02/article2.pdf

Safe by default: Val’s foundation of mutable value semantics ensures that ordinary code is memory safe, typesafe, and data-race-free. By explicit, auditable opt-in, programmers can use unsafe constructs for performance where necessary, and can build safe constructs using unsafe ones.

Versus Carbon:

Carbon's premise is that C++ users can't give up performance to get safety.

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

college_physics3• 4 years ago

Its a bit disappointing that the C++ community and stakeholders haven't found a way to address perceived shortcomings and (why not) reinvigorate and generate excitement about the ecosystem. The fact that people choose to embark on enormous investments to build alternatives from scratch (e.g Rust) might suggest that the cost calculus between maintaining compatibility with legacy code and future-proofing the language has now shifted decidedly against the former. C++ does not feel like the kind of beast that is destined to become the new COBOL. Its continuing popularity in game development is just one of the areas that could see enormous growth and evolution.

int_19h5• 4 years ago

I very much doubt that existing large C++ codebases - which are plenty - are going to fully or largely migrate to Rust (or whatever) within the next two decades. Given that C++ originates in mid-80s, that would make it as old as COBOL was in 2000.

nindalf5• 4 years ago

This is similar to saying that no one would migrate to TypeScript because there are so many existing JavaScript codebases. The success of TypeScript and Kotlin suggest that one of the languages that hope to interoperate with C++ like Carbon could become more popular over time.

still_grokking43• 4 years ago

C++ does not feel like the kind of beast that is destined to become the new COBOL.

Strange conclusion.

For me it looks like C++ has chosen to become exactly this. The only reason it's still relevant is all the legacy code. Almost no new projects get started in C++. So it looks like they double down on that.

Its continuing popularity in game development is just one of the areas that could see enormous growth and evolution.

I don't see this. Game dev is also moving.

The most popular engines may be written in C++, because there was no choice as this projects started. But the games made on those engines are mostly not written in C++.

Most code in games is "script like". And it's even often written in scripting languages. When not, it's something like C#, or some other more modern high level language.

college_physics3• 4 years ago

Strange conclusion

I don't have a crystal ball but there are important differentiating factors: C++ is much more capable and it is relevant in more diverse domains whereas COBOL was very confined.

Game dev is also moving

There are several new ECS projects implemented in C++ that have enthousiastic following.

My hunch is that it is still up to the C++ world to lose it entrenched position by not doing the right changes but maybe that won't be the case in a few years from now.

nindalf5• 4 years ago

Just another request to stop citing Tiobe. This index is misleading and harmful.

https://blog.nindalf.com/posts/stop-citing-tiobe/

still_grokking43• 4 years ago

Where's the petition? Need to sign it!

Tiobe is outright nonsense.

Citing it (besides jokes) is usually a sign that you can't trust the source that does so in the first place. Really everybody should know (at least for the last few years) that the Tiobe index is just completely made up nonsense.

lizardactivist• 4 years ago

I haven't kept up with C++ for over a decade, but the little glimpses I catch of it makes me think that though it has received good and useful stuff, it has also grown needlessly complex.

Raptor22• 4 years ago

Can someone explain the differences between Google and the C++ standards committee? I understand it has to do with breaking ABI, but what exactly does this imply?

As someone much more experienced in other languages like Python and Swift, my biggest surprise when using C++ is that the language standard and the compiler are two different things. In Python, the default CPython interpreter is the standard - if it's not in CPython, it's not standard Python. But in C++, there's like 3 different compilers, all of which implement different subsets of the latest C++ standards. IIRC, the latest standard that all compilers implement fully is C++ 14. I understand C++ is a broad and complicated language, and I actually have liked using it in the few times I've had the chance, but the compiler/standard situation seems like complete lunacy from where I stand.

deng• 4 years ago

As someone much more experienced in other languages like Python and Swift, my biggest surprise when using C++ is that the language standard and the compiler are two different things.

Yes, that's because C++ is a formally standardized language, and Python and Swift are not. C++ is an ISO standard, and it is published in text form. You are free to create your own compiler, and if it works according to the rules written in the official standard, you may call it a standard-conforming compiler. There are of course other languages which are also officially standardized like this (does not have to be ISO), for instance Common Lisp, Scheme and of course Javascript (ECMA). If a language is defined by a reference implementation, then this is an informal way of standardizing your language, and if you want to create your own compiler/interpreter for such a language, you have to carefully evaluate what the reference implementation does.

I understand it has to do with breaking ABI, but what exactly does this imply?

Very roughly, it means that you cannot link object code with the current ABI with object code that was generated by older compilers with the old ABI (well, it's usually worse: you can link just fine, but your program might or might not crash). This is not unprecedented in C++, we had this when switching from gcc4 to gcc5, it was definitely pretty painful and I'd rather not have this again.

yeputons• 4 years ago

Google is a company which uses C++ in a specific way. For example, they build most of their code from source with the same compiler and compilation settings, including external dependencies. They do not use exceptions, some parts of the standard library, some parts of the language. They also can upgrade their codebase in more-or-less atomic company-wide refactorings which also run most (if not all) tests for the affected code.

The C++ standards committee is a body of people from different backgrounds, different companies and different needs from C++. Moreover, they kind of have to cater to everybody. There may be people programming microcontrollers, there may be game developers, there may be people supporting/porting decades-old software which uses old versions of Qt, there may be people wanting all the modern bells and whistles in C++, and there may be people using pre-compiled third-party libraries from a long gone vendor or vendor not willing to upgrade their compiler.

These needs may contradict each other. ABI (Application Binary Interface) in C++ can be thought of as a `.pyc` file in Python. You don't expect _any_ compatibility of `.pyc` files between Python versions, so all libraries are distributed in source code in `.py`, and it's up to Python to process them into `.pyc` files as it wants. In C++ world, lots of libraries (including all OS libraries, actually) are distributed in a pre-compiled binary form only. The way your program interacts with the library is the ABI. If you upgrade your compiler, but the library does not, you can no longer use the library.

One example is the memory layout of standard library types. E.g. a release version of `std::vector` (the standard dynamic array container) may only need three fields: a pointer to the allocated memory, maximal capacity of the vector, and its current size. A debug version may also include stuff like "where this vector was created". If one part of your program (or an external library) expects a vector to be 24 bytes and have such and such fields, and another part expects something else, Everyone Dies(tm). To make things worse, everything breaks silently: there are little to no checks for ABI compatibility, and reading a byte almost always works.

As to why the standard is affected by this, even though "ABI" is not mentioned anywhere in the text: you cannot add/remove fields or virtual methods within the standard library in the next standard. If you do, the newer standard library _must_ become incompatible with all the pre-compiled code expecting the older version. (Almost) no way around it. A similar thing in Python would be if one has tried to use both Python 2 and Python in the same project simultaneously, in the same process.

So if everyone starts building all their code and dependencies from the source code, there will be no ABI concerns anymore. I don't see it happening any time.

IIRC, the latest standard that all compilers implement fully is C++ 14.

Not even than, garbage collection from C++11 was never implemented by any compiler: https://en.cppreference.com/w/cpp/compiler_support/11

Not a big problem though, as it's never used by anyone. I've heard of people using non-standard garbage collection extensions instead, long before C++11. That's another thing with the standard and compilers: not everyone needs every feature, so some are given a priority depending on the compiler's users. And there are lots of existing solutions which probably won't be migrated to the standard.

pjmlp15• 4 years ago

I've heard of people using non-standard garbage collection extensions instead, long before C++11.

Anyone using Unreal C++, Managed C++ (.NET 1.0) or C++/CLI (.NET 2.0 onwards).

raymond_goo• 4 years ago

Ctrl-F "networking", close tab...

C++ at the End of 2022

Related Stories