Dropping support for old C++ standards(lists.boost.org) |
Dropping support for old C++ standards(lists.boost.org) |
This is patchworked around in more easygoing languages with dependency management systems, docker containers, etc. etc. but if you can enforce living at head from the start it makes everyone's life easier.
https://abseil.io/about/philosophy#we-recommend-that-you-cho...
I can no longer count the number of times we had an issue with a "supposedly" minor release that ended up breaking major things in our stack. Most of them were things that could have been detected using unit tests or some kind of basic regression testing.
If you have a 1000 dependency packages, and at any point in time 0.1% of them are broken, then odds are you will always have something broken.
Having 1000 dependencies with versions pinned means you are living alone and will run into fewer issues, but when they do come, they will be absolute nightmares that no one else is dealing with and no one can help with. And one day you'll have to do the game of begging someone else to upgrade their version of a downstream thing to fix the issue, and they won't, so you'll try to get the other group to backport the fix in their thing to the version you can't upgrade off. And they won't. etc. etc.
Full versioning is the worst of all approaches, IMO, for large complex interconnected codebases (especially ones that are many-to-many from libraries to output binaries) but it absolutely is sometimes the only viable one (for example, the entire open-source-ecosystem is a giant(er) version of this problem, and in that space, versioning is the only thing that I can imagine working).
But you do say “okay, C++20 is released, let’s fix all the build errors and deploy it company-wide.”
Also, living at the HEAD of your language standard is quite a bit different from living at the HEAD of other dependencies.
A lot of companies/products do not work that way. Some have physical products out there that have to be updated, some have on-premises deployments, some sell user software of which there are multiple versions under support. Each of these live versions have to have their own source branches and dependency trees. A single `:latest` can render future bugfixes unbuildable.
Definitely not the end of the world. Said SDKs & build scripts are available here: https://github.com/ossia/sdk for anyone interested (I'll be honest though: the scripts are a mess!)
Assuming you have these lockfiles, you have the typical option, which would be to make a lockfile for each released entity, record it for later reproduction, and update it at least every release.
The "live at head" approach would be to instead have a main shared lockfile for every project in the company in a recorded sequence. All projects pick a version of that lockfile to release from. Practically speaking, all projects probably just take the latest version (the head) of that lockfile and everyone works hard to make sure that lockfile always works for everyone.
The main advantage here is pretty straightforward combinatorial math. Maintaining and validating unique combinations of dependencies for every release in a codebase is NP-silly, whereas sharing one set of dependencies across as many applications as possible isn't easy but it has a much nicer cost curve. In theory at least, but a lot of large organizations claim practice backs the theory up as well.
[1] Versioning doesn't have to work this way. Putting all code into one big source repository (vendoring) has the same effect.
In contrast, those third-party projects like boost would probably consider the latest commit on their HEADs of their git repos to be "head". So "live at head" is a statement about how each organization should version its dependencies. It doesn't really make sense in the context of boost maintainers deciding their support surfaces since they have all the "heads" to worry about, inherently -- all the organizations using boost libraries.
Backward compatibility is good to have, but C++ needs for alternatives that allow it to drop support for old things, because the language needs to evolve and backward compatibility is preventing it, and it turns into very very long compile time.
And even if backward compatibility is out in C++, it would break in the language, not in the ABI, so old C++ and new C++ could still easily cohabit together, quite like C has always lived with C++ for a long time now.
I like C++, but nobody denies that C++ carries a lot of weight for being disliked.
[0]: https://github.com/seanbaxter/circle/blob/master/new-circle/...
People point out RedHat provide newer compilers (and newer patched C++ standard libraries depending on the default one!) and he says "It's not us, it's our customers. And no, they won't use any compiler which isn't the system default".
Either you only use the system defaults, and that includes the old Boost included with RHEL, or you don't. I guess he includes a private Boost copy as part of his project. Well, include a private GCC too then. A dependency is a dependency
Those customers have silly requirements for no reason. The whole world shouldn't make efforts to accommodate them.
I am going to bet those customers are going to argue about "stability". All this comes from people reading "stable" as "rock solid, never crashes, always works as expected" when in the case of RHEL it actually means "it doesn't change, no new bugs introduced, and you can relly on the old bugs staying there". Those customers just need educating.
When not, others will.
Library A uses Boost and requires an older version of GCC. Library B uses Boost and requires the newer version of Boost. You want to use libraries A and B in the same project, what now?
but the same question applies to Library B: if your regulations state that you can't update your compiler version past the default distro one, why can you bring in some random recent libraries that are definitely not part of the distro since they depend on a Boost version that is more recent than the one your distro provides?
Of course this all very stupid when you can install GCC 11 and compile in C++20 mode on RH 7 with the official devtoolsets...
But the core problem is as always to tie compilers to linux distros, like a C++ compiler version is relevant in any way to your operating system's stability...
Or pay RedHat to backport the library B to the old Boost for you :)
The vast majority of the time it is just not worth it.
Build each one as a separate shared library and wrap each one with a C interface?
this greatly extends of what can be considered supported by RHEL 7 (unless we require - "don't install any packages")
And then IBM’s OS/400 ILEC++ support isn’t even up to C++11.
It is hard to live in Enterprise software land where you support everything for a lot of years, but end up stuck on older third party libraries when they move to new standards to keep parity across your product line’s feature set.
There was a Linux migration project to move the company to Linux. I haven’t heard anything from people inside, but I’m willing to bet that there are still some stragglers that haven’t moved yet.
With .NET 8 and Java 21 around the corner,....
It feels like living the Python 2 / 3 transition.
The wonderfull enterprise land.
But the old one is crufty and barely maintained and nobody wants to touch it, and the new one is only using one feature of the new version of Boost, so it's a easier to blacklist the newer version of Boost than to overhaul all the old code. But is that what we wanted to cause?
Moreover, with widely used core libraries like this, that sort of thing happens repeatedly, and now the downstream users have to do work they wouldn't have had to do if compatibility was maintained. At scale probably a lot more work than it would be for the widely used thing to maintain compatibility. That seems bad.
- "Wants" "stable", i.e. the default gcc
- Doesn't care what Boost version is used
- Pays the developer
The developer
- Wants the latest toolchain
- Wants the latest Boost
- Makes money
The developer
- Accepts using an old compiler because Boost keeps compatibility with it
- Does not pay Boost developers for it
There is no single entity that wants old compiler (other than to satisfy others) and new Boost.
I have used many libraries that use boost internally (often in a custom namespace) but do not expose it on the API
The real problem is when you have a big pile of ancient, unmaintained code that uses long-deprecated stuff. At that point, no, you really can't expect to seamlessly interoperate with new code.
Each upstream commit didn't land directly into the monorepo, instead there was a long lived branch, and on the compiler team there was a buildcop rotation responsible for doing an integrate from that branch into //third_party/llvm. This included running the tests (and fixing any problems) for any other software that depends on LLVM as well as building an unstable crosstool and doing some basic smoke tests on that. Taking that crosstool through testing and to stable crosstool was the responsibility of a different buildcop rotation, using a special compiler team tool for testing the testing crosstool nightly, then to release to stable we used the ordinary presubmits, but for all projects at once, making its testing as similar as possible to any normal code change.
Not only is ISO full of DR and things that probably shouldn't have been standardized in first place (thankfully some of them were latter removed), there is plethora of compilers to chose from.
By the time all of that is supported for a language release we are on the next one, and I value that pipelene more than the changes currently being made.
Granted, the former can be quite a bit more severe - but that’s why we should do things like build on dedicated servers with restricted access to the internet etc.
This works as long as compatiblity-breaking changes are kept rare so that you can feasibly have someone doing security updates for each of the incompatible versions.
Most libraries have network access, but even if they didn't, supply chain attacks could be relavent (but probably less generic)
I don't know about all of them, but a lot of them have CI set up such that HEAD is never broken for some definition of broken.
Practically speaking it's basically impossible to fuzz test everything, but typically builds and reasonably fast and reliable tests are run before HEAD includes new changes.
Being efficient about supporting this workflow is more or less what monorepo build systems like bazel, buck, and pants were designed for.
The correct word here is not advantage but risk.
While making a product you rely on something, some other product/package. Thousand of them if you are unlucky. If you have 1000 packages to collaborate in the development/testing/QA of them you will do nothing else! Also try building a house on a concrete that is still maturing, with tools not ready yet, I dare you! Careful developers rely on reliable things. It is a shame in this industry this is not available. Either released(!) things are not ready yet, or are in demise already, the sweet spot is tiny.
In practice A and B would each have their own namespaces in C++ codebases, but that wouldn't resolve the tension if each wanted a different version of boost. One approach to resolve that tension is to figure out how to have two versions of boost in the same dependency tree. The below is addressing that proposal.
---
Practically, no. You could certainly create a new namespace C++ names: functions, classes, global variables, and so on.
But there are other "names" in C++ that don't respect C++ namespaces: C symbols, included headers, preprocessor names, and library names (as in `-lfoobar` on a link line). You'd need to make up new names for all of these and possibly a few more things to make a full duplicate of a library.
Now, if you managed to do all that, there are still problems to watch out for. For instance, it's common for projects to assume that global or static names in a C++ namespace can be treated as unique process-wide values in a running program. As in, `mynamespace::important_mutex` might guard access to specific hardware, so having a `mynamespace2::important_mutex` also thinking it has the same job would be bad.
And if that wasn't a problem, you still have to think about types that show up in APIs. How will downstream code be written when you have a `boost::string_ref` and a `boost2::string_ref` in the same codebase? Which `string_ref` do you use where? Can you efficiently convert from one to the other as needed? Will that require changing a lot of downstream code?
At the limit a stale interface is a C interface, but it doesn't have to be. GCC std types are fairly stable, and Qt manages a rich interface while maintaining robust ABI compatibility. It is hard work, and not always worth it of course.
Note that it's not just mutexes. The same can happen with other kinds of "one per process" resources: memory pools, thread pools, connection pools, caches, registry objects, etc.
Even more fun when two dependencies both use different versions of the same lib.
I much prefer bringing everything into our source tree up front and doing the build ourselves rather than just linking a prebuilt lib but sometimes you don't have that option.
e.g. You have Library A using LibDependency-1.0.0 and Library B using a separately compiled LibDependency-2.0.0? Then have MyAwesomeApp linking LibA and LibB and just accept the binary+memory overhead of two copies (albeit different versions) of LibDependency?
Rather than trying to do this at the language level with namespaces or whatever, it's probably easier to compile and link each version of the problem dependency into a separate library (static or dynamic), then to make sure each of your own libraries and executables only directly links to one version of the problem library.
This way, you don't have to rename or namespace anything, because conflicting names will only be exposed externally if you're linking to the problem library dynamically, in which case you should be able to arrange for the names to be qualified by the identity of the correct version of the problem library at dynamic load time (how to ensure this is platform-specific).
LibDependency.h:
typedef struct SomeOpaqueLibDependencyType * SomeOpaqueLibDependencyTypeRef;
SomeOpaqueLibDependencyTypeRef MakeTheThing();
void UseTheThing(SomeOpaqueLibDependencyTypeRef);
LibraryA:
...
SomeOpaqueLibDependencyTypeRef getSomething();
LibraryB:
...
void doSomething(SomeOpaqueLibDependencyTypeRef);
MyAwesomeApp:
LibraryB.doSomething(LibraryA.getSomething()) // pseudocode
As a library author there are things you can do for ABI compatibility, but they all basically boil down to providing a bunch of non-opaque API types that have some kind of versioning (it's either an explicit version number, or it's a slightly implicit size field which IIRC is the MS standard). You also have opaque types where the exposure of details is more more restricted, generally either just an opaque pointer, or maybe a pointer to a type that has a vtable (either an automatic one or a manually constructed one). In general use of the non-opaque portions of the API are fairly restricted because they have ABI implications, so a user of a library will communicate by providing those non opaque data to the library, but the library will provide largely opaque results with an ABI stable API that can be used to ask questions of an otherwise opaque type.
This works in general, and it means you don't have to rebuild everything from scratch any time you update anything. It breaks down however when you have different versions of the same library in the same process. The problem is that while you see a single opaque type, it's not opaque to the library itself so while an opaque type from two different versions of a library may look the same to you, the implementation may differ between the two versions. Take a hypothetical:
LibDependency.h:
typedef struct OpaqueArray *ArrayRef;
struct ArrayCallbacks {
int version;
size_t elementSize;
void (*destroyElement)(void *);
void (*copyElement)(void *, const void*);
};
ArrayRef ArrayCreate(const ArrayCallbacks*, size_t);
void ArraySet(ArrayRef, size_t, void*);
void *ArrayGet(ArrayRef, size_t);
LibDependency-1.0.c:
struct InternalArrayCallbacks {
void (*destroyElement)(void *);
void (*copyElement)(void *, const void*);
};
struct OpaqueArray {
InternalArrayCallbacks callbacks;
size_t elementSize;
char buffer[];
}
ArrayRef ArrayCreate(const ArrayCallbacks* callbacks, size_t size) {
size_t allocationSize = sizeof(OpaqueArray) + size * callbacks->elementSize;
OpaqueArray *result = (OpaqueArray *)malloc(allocationSize);
/* initialize result, copy appropriate callbacks, etc */
return result;
}
void ArraySet(ArrayRef array, size_t idx, void* value) {
array->callbacks.copyElement(array->buffer + idx * array->elementSize, value);
}
Now v1.1 says "oh maybe we should bounds check":
LibDependency-1.1.c:
...
struct OpaqueArray {
InternalArrayCallbacks callbacks;
size_t elementSize;
size_t maxSize;
char buffer[];
}
...
void ArraySet(ArrayRef array, size_t idx, void* value) {
if (idx >= array->maxSize) abort();
array->callbacks.copyElement(array->buffer + idx * array->elementSize, value);
}
As a library implementor there's a lot you have to do and/or think about to ensure ABI stability, and it is manageable, but more or less all of the techniques break down when the scenario is "multiple versions of the same library inside a single process".
So taken to extreme, some Boost libraries might become VC++ only, for authors that decide to go fully on ISO C++ 20 and 23.
See their C++20 support versus VC++.
How were GC API, auto_ptr, modules, concepts and co-routines pretty well tested?
In those three compilers they surely weren't, so in which ones?
And folks using a full stack of MS tooling are probably using the EDG compiler as an implementation detail for IntelliSense support.