Date: Thu, 11 Jul 2024 20:28:00 +0000
The statement "I do not think this is a problem" is inaccurate, I think it is a problem, it is a big problem.
We just disagree on what exactly the problem is. The question was rhetorical to lead you to the actual problem.
And you kind of hinted at what that is.
"Not everyone has the luxury of being able to 'just recompile their code'. Some libraries are distributed in binary form only. To support these people [...]"
And therein lies the problem. It's a problem of managing already compiled code, using one definition, and combining it with new code using a different definition.
Code generated on the same platform have the problem that you have different compiler vendors and different library implementations of things.
If you are talking about "static libraries", a library produced by a particular compiler vendor can not be linked with a different compiler vendor.
The file formats are not the same, the concepts they use differ, they just don't talk the same language. Even libraries produced by the same compiler vendor on different versions are not even guaranteed to work.
So, this is just a dead end, if you are not compiling the whole thing with the same "exact" compiler, if it works at all is a miracle.
Dynamic libraries have a similar problem, if two compiler vendors can not agree on an implementation to use (not to mention name mangling rules), how do you expect them to agree on adopting a consistent numerical definition that describes the particular implementation adopted?
Short of sharing the source code itself (at that point why not just compile the whole thing) how would you even know that the expected behavior of the individual bits that compose the object is compatible?
The answer is you wouldn't.
Unlike C, C++ defines data structures that should exist, but doesn't define what they should look like. Specifically, because they could look differently, i.e. different ABI is allowed, so that it can be optimized.
We can sit here and pretend all day that this practice of "having precompiled libraries with C++ interfaces, and we are able to upgrade the language without touching those" works, but the problem is, it doesn't!
I personally think that concerns of breaking ABI are often unwarranted, and that the committee is being overly conservative about not breaking ABI, and that this is holding the language back!
If it was up to me, I would have removed most of the lint, completely bulldozing the ABI... want to use the new thing? Just recompile the code, like perhaps you should have! You can't? Tough! Then you don't get to use the new thing!
Which in practice is already a thing every time there's a new standard. You got to break those eggs!
Forcing an ABI is essentially trying to solve a problem of library management, which is a losing battle given that binary code generation is not part of the standard.
That's the real problem, and I don't believe that a magic function could solve that.
-----Original Message-----
From: Hans <hguijtra_at_xs4all.nl>
Sent: Thursday, July 11, 2024 21:40
To: Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_lists.isocpp.org
Subject: Re: [std-proposals] ABI
On 11/07/2024 21:27, Tiago Freire wrote:
>> It solves the problem that classes, once added to the standard library, immediately fossilize, and are no longer eligible for any kind of optimisation or evolution that would change their ABI.
>
> I just recompile my code, why would that be a problem? I change ABI on my personal libraries all the time, never had a problem.
> It's a rhetorical question, that is not your real-world problem. Your problem is something else, I want to get to that.
We could have come to this point without me spending hours answering your questions, simply by you stating "I do not think this is a problem".
Not everyone has the luxury of being able to 'just recompile their code'. Some libraries are distributed in binary form only. To support these people, the committee has adopted a policy of not making any changes that would affect ABI. This is a real-world problem that affects library evolution, both in terms of optimisation and in terms of additional features. Well-known classes that are sub-optimal and cannot be improved due to ABI concerns include std::regex, std::deque, and std::unordered_map. And std::jthread could just have been a small extension to std::thread, except that it would have changed ABI, so a new class was necessary.
If you disagree this is something that needs to be addressed at all, just say so, and kindly do try to motivate it with something that goes further than just your personal needs.
Hans Guijt
We just disagree on what exactly the problem is. The question was rhetorical to lead you to the actual problem.
And you kind of hinted at what that is.
"Not everyone has the luxury of being able to 'just recompile their code'. Some libraries are distributed in binary form only. To support these people [...]"
And therein lies the problem. It's a problem of managing already compiled code, using one definition, and combining it with new code using a different definition.
Code generated on the same platform have the problem that you have different compiler vendors and different library implementations of things.
If you are talking about "static libraries", a library produced by a particular compiler vendor can not be linked with a different compiler vendor.
The file formats are not the same, the concepts they use differ, they just don't talk the same language. Even libraries produced by the same compiler vendor on different versions are not even guaranteed to work.
So, this is just a dead end, if you are not compiling the whole thing with the same "exact" compiler, if it works at all is a miracle.
Dynamic libraries have a similar problem, if two compiler vendors can not agree on an implementation to use (not to mention name mangling rules), how do you expect them to agree on adopting a consistent numerical definition that describes the particular implementation adopted?
Short of sharing the source code itself (at that point why not just compile the whole thing) how would you even know that the expected behavior of the individual bits that compose the object is compatible?
The answer is you wouldn't.
Unlike C, C++ defines data structures that should exist, but doesn't define what they should look like. Specifically, because they could look differently, i.e. different ABI is allowed, so that it can be optimized.
We can sit here and pretend all day that this practice of "having precompiled libraries with C++ interfaces, and we are able to upgrade the language without touching those" works, but the problem is, it doesn't!
I personally think that concerns of breaking ABI are often unwarranted, and that the committee is being overly conservative about not breaking ABI, and that this is holding the language back!
If it was up to me, I would have removed most of the lint, completely bulldozing the ABI... want to use the new thing? Just recompile the code, like perhaps you should have! You can't? Tough! Then you don't get to use the new thing!
Which in practice is already a thing every time there's a new standard. You got to break those eggs!
Forcing an ABI is essentially trying to solve a problem of library management, which is a losing battle given that binary code generation is not part of the standard.
That's the real problem, and I don't believe that a magic function could solve that.
-----Original Message-----
From: Hans <hguijtra_at_xs4all.nl>
Sent: Thursday, July 11, 2024 21:40
To: Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_lists.isocpp.org
Subject: Re: [std-proposals] ABI
On 11/07/2024 21:27, Tiago Freire wrote:
>> It solves the problem that classes, once added to the standard library, immediately fossilize, and are no longer eligible for any kind of optimisation or evolution that would change their ABI.
>
> I just recompile my code, why would that be a problem? I change ABI on my personal libraries all the time, never had a problem.
> It's a rhetorical question, that is not your real-world problem. Your problem is something else, I want to get to that.
We could have come to this point without me spending hours answering your questions, simply by you stating "I do not think this is a problem".
Not everyone has the luxury of being able to 'just recompile their code'. Some libraries are distributed in binary form only. To support these people, the committee has adopted a policy of not making any changes that would affect ABI. This is a real-world problem that affects library evolution, both in terms of optimisation and in terms of additional features. Well-known classes that are sub-optimal and cannot be improved due to ABI concerns include std::regex, std::deque, and std::unordered_map. And std::jthread could just have been a small extension to std::thread, except that it would have changed ABI, so a new class was necessary.
If you disagree this is something that needs to be addressed at all, just say so, and kindly do try to motivate it with something that goes further than just your personal needs.
Hans Guijt
Received on 2024-07-11 20:28:04