C++ Logo

std-proposals

Advanced search

[std-proposals] ABI breaks

From: Avi Kivity <avi_at_[hidden]>
Date: Sun, 08 Jun 2025 11:45:19 +0300
On Sun, 2025-06-08 at 00:24 +0300, Ville Voutilainen wrote:
> On Sun, 8 Jun 2025 at 00:20, Avi Kivity <avi_at_[hidden]> wrote:
>
> > That's easy. The hard part is figuring out how to deploy such a
> > type
> > with the same name as its previous version that didn't use
> > the dummy value protocol. It's a behavioral ABI break without any
> > layout ABI break.
> >
> >
> >
> > This was solved already when std::string changed its ABI. The
> > compilers shipped the standard library compiled in both modes for a
> > while, then dropped the old mode.
>
> Sure, but it was painful. Very painful. It's not quite that painful
> for std::optional, because it's not used elsewhere in the library
> internals.
> But still, it's painful.


It wasn't painful for me - I barely noticed it. Of course, everyone's
mileage varies.

In my opinion, in these days of containers, it's much easier to support
multiple ABIs.


>
> > Of course this little thing isn't worth the trouble, but libraries
> > could use a spring cleaning anyway (like make std::deque's default
> > constructor not allocate) and this could be added on top. Library
> > vendors that choose not to improve, would simply not implement the
> > feature.
>
> I don't think the cost of the next ABI break goes to zero after the
> first one, so it isn't immediately obvious to me that such a change
> would necessarily open
> a practical door to making more breaks. It probably would, but that
> does depend on how much a nuisance the first one is and how much time
> is left for the following
> ones. :)


I don't think the Standard should concern itself with ABIs. It should
promote source compatibility. It should be up to the vendors to decide
whether to race ahead or be conservative.

It's silly that some random decision that Jonathan Wakely's
predecessor's predecessor's [repeat as required] predecessor made
should affect the performance of std::map for millions or even billions
of cores, which look nowhere near like the cores at the time the STL
was written.

Distribution vendors already rebuild all their packages for each major
release, and third-party vendors already build for multiple
architectures. Having them build for the most recent and next-recent
ABI is annoying, but not more than that.

Received on 2025-06-08 08:45:25