pt., 12 lip 2024 o 00:58 Henry Miller via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> There are many who have lost company politics and so cannot recompile their existing code. There is code from a third party where the code is owned and built by a third party and so every recompile will cost significant money (half of it paid to them, half in support costs getting the compiler to them - this second also implies significant opportunity cost lost because those people are not doing something else). There is even code where the source is lost and you can't rebuild it at any price. Unfortunately I don't see how this (or anything else) can address those problems.
>

How exactly will a change in standard help here? most of this code
could even be from C++98 and all ABI stable types will be in C++26.
Not to mention that all these libs need to use these tools. otherwise
even if C++ gives you these types, libraries will not be portable.

I think lot better would be to have way to have both old and new types
in same sources like:

```
void foo(std::cxx98::string s, std::string& b)
{
    b = s;
}
```

Some time ago I float around extending `extern "C++98" { }` to allow
to compile old code using old rules in a translation unit that
uses the new standard. But people here said that would not work in
every case and could have some corner cases.

Question is if modules could help here? like I compile one and pretend
this is C++98 code (aside from the module parts).
And when I link it with the rest of the code it uses types that have
correct old ABI and even if compiled directly should
have diffrent ABI.



> There is a second problem: as time has passed programmers/C++ have learned. There are changes that it would be nice to make but it breaks ABI so we don't. Sometimes it is internal to the library and so an all new library can do better, sometimes it is the C++ standard that is not optimal. (AFAIK it is pure luck that std::vector is so cache friendly, but some future CPU may have some unknown change that makes it terrible and we would want to change). Of course you don't need std::stable::string you need std::string_two (or any other bike shed name). Again, I don't see who this helps - we might make some ABI changes before making stable::vector, but there is no particular reason to think that we will get the final ABI right for all time if we try today, so we can't put this into std::stable lest we be wrong.
>

`std2::` and after long time `std3::`

> There is a third problem: interoperability. I'd love to have containers that I can share between C, C++, Rust, ada, zig, Go, Java, python (insert your favorite here) without a lot of effort writing wrappers. ABI isn't really an issue here, but C++'s name mangling and V- tables (which like ABI are not even in the C++ standard, but it is hard to implement C++ without) make it effectively impossible to use anything in std:: (D can apparently do this), Of course you can look up your platform name mangling rules and where the vtable lives (some platforms document this, others it is reverse engineer) and call any C++ function as a C function - nobody sane will allow this in production code though. Are you instead asking for some form of ISO::string, ISO::vector, ... - all new containers with a defined ABI such that you can implement and use them in any language?
>
> Those are the 3 different problems I see others talking about. They are different issues. In none of them do I see adding std::stable adding any value.
>
> Just remember, our predecessors were smart people too. While we know things they got wrong, we don't know how the world will change and thus what we will get wrong. That shouldn't stop us from trying to do better, but it should stop us from thinking we will get things perfect. Sometimes we won't even be able to agree on what better is.
>
> --
> Henry Miller
> hank_at_[hidden]
>
> On Thu, Jul 11, 2024, at 15:28, Tiago Freire via Std-Proposals wrote:
> > 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_[hidden]>
> > Sent: Thursday, July 11, 2024 21:40
> > To: Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden]
> > 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
> >
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals