"Breaking ABI" isn't an issue unless you can't compile your code anymore. It's pathetic that C++ has been so hamstrung over ABI that we're willing to stop improving.

▲

knorker 4 days ago | parent | next [-]

Not everyone works at Google and builds all binaries from scratch from a monorepo every time. And even then, maybe even Google doesn't rebuild libstdc++ as part of this.

GNURadio consistently uses pimpl for blocks, as I understand it mainly for ABI.

> willing to stop improving.

I think that dismissing it like that shows a naive understanding of execution environments, binary interface design, and in general systems software engineering.

▲

StilesCrisis 3 days ago | parent [-]

If you want a fixed build environment, pick a toolchain and stick with it.

If you want the latest and greatest, a willingness to rebuild your code seems like a reasonable prerequisite to me.

If you need a binary blob that can withstand toolchain versioning, use a dynamically linked library.

	▲	knorker a day ago \| parent [-]
		Not sure what toolchain has to do with your code retaining ABI compat like size. Nor how dynamic linked library helps. Dynamic linked libraries are exactly the ones that have the most use for pimpl to maintain ABI compat.

▲

pjmlp 3 days ago | parent | prev | next [-]

Because outside Linux and BSD distros, the large majority of C and C++ developers care about binary libraries, and companies do make a business out of it.

So regardless of what WG14 and WG21 do, compiler vendors will ignore them, if it means angry customers.

In design by committee languages, new standards are only relevant to the extent implementers actually care about them.

▲

bluGill 4 days ago | parent | prev [-]

Unfortunately I have some customers of my library that won't recompile. Hard to blame them because it is safety critical and needs recertification. In just glad the certification process is willing to not recertify my code when I change it