On 6/22/2014 5:51 PM, Botond Ballo wrote:
----- 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.
I suspect you're misdiagnosing the problem. There are several reasons
why people might use C instead of C++ for public APIs:
1. Their library is in C [because C++ is complex/slow/foreign/etc.]
2. C is "more" ABI stable than C++
3. Want to easily differentiate between a "stable" C interface and an
"unstable" C++ interface.
4. C hooks into other languages' FFIs much more easily.
I can name several projects that use C++ public interfaces (QT,
SpiderMonkey, ICU, Boost, several GObject-based libraries also have C++
bindings). I think the real problem for ABIs is the difficulty of
getting a working FFI for other languages--and the proposed draft does
absolutely nothing to solve that problem. Standardizing even a small
subset of C++ in terms of an equivalent C ABI (standard layout structs,
basic vtables, and related name manglings) would go a long way to making
it more usable. And it also wouldn't require redefining an extern "abi"
value [1]
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
I think this is overstated. As I recall, the only compiler with
significant issues is MSVC, and part of that is the instability of the
standard library and part of that is the pointer-to-member-function in
the MSVC ABI being completely braindead (it's completely dependent on
how the class is defined, so in lieu of a definition, there are compiler
options to reorganize it). If instead of trying to define the complete
ABI, you focused on a subset--and you defined that ABI in terms of a C
ABI--you get much of the desiderata without requiring too much pain on
either compiler writers or on library writers.
What exactly would we be stuck with for decades?
A useless std::abi.
[1] I know ELF makes providing multiple symbol "names" relatively easy,
and I think Mach-O and PE/COFF have similar functionality, so supporting
multiple name manglings for the same function is not difficult. There's
a minor stumbling block in how MSVC does vtable layout when overloading
is involved, but otherwise, most of the "basic" layout is pretty sane.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
