Date: Sun, 07 Aug 2022 12:06:28 -0700
On Sunday, 7 August 2022 11:31:36 PDT Jason McKesson via Std-Proposals wrote:
> The `std::string` change only affected your code if you used
> `std::string` to communicate with code outside of your static
> compilation/linking. And the thing is... there actually wasn't all
> *that* much such code. That's not to say that there was none, but it
> wasn't a huge amount. There are entire libraries that don't deal in
> strings at their interface sites, or just don't use `std::string`
> directly in interfaces.
I don't know where you get your data and you may actually be right that it
wasn't much code that actually passed std::string across dynamic library
boundaries... but so long as *one* function did in a shared library, it needed
to be recompiled, and then you needed to inspect this library's downstream
dependencies too. So in effect, the whole C++ world had to be recompiled when
this happened.
Aside from some code that refused to use the Standard Library in its own ABI,
like Qt 4 did.
> Indeed, not using standard library types in interfaces is quite
> common, specifically to avoid such ABI problems.
>
> By contrast, the kind of ABI change you're talking about would
> effectively break *every function* that happens to use *any* by-value
> parameter of a user-defined type. That's a *lot* more code.
I suspect that it would cause the recompilation rate to go from 97% to 99.9%.
So in absolute terms it's not much.
In effort, it might be. Some of those remaining 3% may be libraries that simply
don't compile any more but are still critical.
Another issue is that a change in ABI of trivial types affect the C language
too. So in this case, not only will the rate be higher, the total population
will be an order of magnitude or two larger. Don't forget that the C ABI is
the interlingua of all the other languages, so you need to update all the
bindings for Python, Java (JNI), Rust, Go, etc.
Finally, another one may be that if an ABI break is in sight, the developers
may take the opportunity to fix defects that have been known for decades. That
may sound like a good thing, except that it has the potential to break stuff is
huge.
> The `std::string` change only affected your code if you used
> `std::string` to communicate with code outside of your static
> compilation/linking. And the thing is... there actually wasn't all
> *that* much such code. That's not to say that there was none, but it
> wasn't a huge amount. There are entire libraries that don't deal in
> strings at their interface sites, or just don't use `std::string`
> directly in interfaces.
I don't know where you get your data and you may actually be right that it
wasn't much code that actually passed std::string across dynamic library
boundaries... but so long as *one* function did in a shared library, it needed
to be recompiled, and then you needed to inspect this library's downstream
dependencies too. So in effect, the whole C++ world had to be recompiled when
this happened.
Aside from some code that refused to use the Standard Library in its own ABI,
like Qt 4 did.
> Indeed, not using standard library types in interfaces is quite
> common, specifically to avoid such ABI problems.
>
> By contrast, the kind of ABI change you're talking about would
> effectively break *every function* that happens to use *any* by-value
> parameter of a user-defined type. That's a *lot* more code.
I suspect that it would cause the recompilation rate to go from 97% to 99.9%.
So in absolute terms it's not much.
In effort, it might be. Some of those remaining 3% may be libraries that simply
don't compile any more but are still critical.
Another issue is that a change in ABI of trivial types affect the C language
too. So in this case, not only will the rate be higher, the total population
will be an order of magnitude or two larger. Don't forget that the C ABI is
the interlingua of all the other languages, so you need to update all the
bindings for Python, Java (JNI), Rust, Go, etc.
Finally, another one may be that if an ABI break is in sight, the developers
may take the opportunity to fix defects that have been known for decades. That
may sound like a good thing, except that it has the potential to break stuff is
huge.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2022-08-07 19:06:30