A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4028

Date: 2014-05-23

Defining a Portable C++ ABI

by Herb Sutter

Excerpt:

Goals, Non-Goals and Constraints

The primary goal is to:

• Enable writing portable C++ code that will be compiled to an object file that can successfully:
  
  link with object files created by other conforming C++ compilers, or different versions of the same compiler, on the same platform; and 
  
  be called using FFIs from other language compilers/runtimes on the same platform, such as Java JNI and .NET PInvoke, if those FFI implementations support the (single) C++ ABI for that platform.

Here a target platform has the same meaning as de facto in C, namely the combination of:

• Operating system: Such as Windows, OS X, Android, iOS, etc. The OS determines things like the binary format (such as PE, COFF, and ELF), the meaning of pointers (such as the legality of stealing low bits and the rules for high bits above bit 48), and more.
• Processor family: Such as x86 or ARM. This affects the instruction set targeted by code generation, alignment, endian-ness, and more.
• Bitness: Such as 32-bit or 64-bit. This affects the size and interpretation of pointers and references, size_t, and ptrdiff_t, and more.

This largely maps to “object files that could reasonably be expected to be part of a single executing program,” since a given single running program will be running on a given OS and processor at a time.

Examples and corollaries:

• It should be possible to ship a single (not “fat”) compiled binary library for Windows x86 32-bit whose interface uses C++ features such as classes, virtual functions, and overloading, and have that be usable with code compiled by other compilers for Windows x86 32-bit.
• It should be possible for an operating system API to expose a well abstracted modern C++ API that uses features like classes, virtual functions, and overloading, and also meets normal OS API requirements for ABI stability.

Notable non-goals and constraints:

• We need not, and should not, try to guarantee some “universal C++ ABI” whereby a single ob-ject file could link with other object files on different platforms, such as 32-bit ARM Linux and 64-bit x86 Windows. That would defeat the original purpose of C and C++ to be a portable lan-guage that can generate executable code that is competitive with handcrafted platform-specific code on a given platform.
• We must not change or restrict anything that is expressible today in platform-specific ways. Any new capabilities must be purely additive. All of the various incompatible compiler option flavors and standard library implementation flavors that are allowed today must still be preserved, both for compatibility and because most of them exist for good reasons (sometimes you do want packing, sometimes you do want a non-default calling convention, etc.).
• We should accommodate that some vendors, such as Microsoft, feel they must be able to break the standard library ABI on every major release (see next section).
• We should accommodate that some vendors, such as GCC, feel they must not break the standard library ABI (see next section).