----- Original Message -----
> From: "Joshua Cranmer 🐧" <pidgeo...@gmail.com>
>
> Is the status quo really that bad?
I think the fact that we're not seeing a proliferation of non-{header-only}
C++ libraries - that is, that people still view C as the go-to language
for ABI stability - is evidence that the status quo is bad.
> MSVC can publish its ABI as is, and
> with the Itanium ABI published as well, that's effectively equivalent to
> saying that the platform ABIs are published. It doesn't necessarily
> solve gcc/msvc compatibility issues, but that's for Mingw to work out.
> If gcc is fixing its std::string without std::abi, then it's not clear
> that std::abi is useful to make ABI guarantees in practice to the degree
> that it's possible. Libc++ appears to do a decent job of making two
> distinct standard C++ libraries operate at an ABI level anyways.
I've been thinking some more about Herb's proposal, and I've come to view
it as consisting of two parts:
1) Codifying the notion of a platform and a platform vendor, and
introducing the requirement that to be conforming:
- a platform vendor must document an ABI;
- this ABI must remain stable for the lifetime of the platform
(so that a change to this ABI constitutes a new platform);
- and compilers targeting a platform must support the platform's
ABI.
I certainly appreciate your point that putting these requirements
into the standard does not magically make them be met. However,
I still think it's valuable, for several reasons:
a) Conforming to the standard is, at least to some extent, an
advertising/selling point for compiler vendors. Having these
requirements in the standard will exert some pressure on
some vendors to meet them. Probably not very much, but it
certainly doesn't hurt.
b) Having these requirements in the standard can change how
C++ developers look at ABI compatibility. It will no longer
be a thing that the standard says nothing about and therefore
no one can rely on - at worst it will be a thing the standard
prescribes but some vendors do not conform to yet.
c) It transforms efforts such as Clang and GCC's attempts to
implement Microsoft's ABI, into something the C++ community
(including the platform vendor in question) makes clear is
not only welcome but expected.
2) Introducing a mechanism to specify which parts of a program, if any,
need to target the platform's ABI. (This is 'extern "abi"' for the
language and 'std::abi' for the library.)
In the absence of such a mechanism, we would essentially be
requiring that all compiler vendors drop their current ABI (if
different from the platform ABI), and target the platform ABI
(which, recall, is supposed to be stable for the platform's
lifetime). This would simply be impractical. As Herb describes
in the paper, compilers today have a plethora of switches that
affect ABI. These exist for a reason, and won't simply go away
overnight. This is why we need a mechanism to say "for this part
of the code, ignore all these switches, and just target the
stable platform ABI". In particular, one would expect authors of
separately-compiled libraries to mark their library interfaces
in this way. Without this, the key benefit of the proposal -
on any given platform, being able to combine binary components
whose interface is marked in this way, no matter what compiler,
compiler version, and compiler switches they have been compiled
with - will not be realized in practice.
> Part of my contention is that backwards compatibility isn't as valuable
> as it appears to be, particular when you're stuck with it for decades.
> It's not clear to me that today is bad enough to warrant making
> something that we'll be stuck with for decades and doesn't really solve
> the problem.
What exactly would we be stuck with for decades?
Cheers,
Botond
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
