4 ms·

Nonsense. C doesn't even define the width of an int, without which an ABI makes no sense. An ABI is a property of a specific target platform (architecture and p

by kentonv 12y ago

Nonsense. C doesn't even define the width of an int, without which an ABI makes no sense. An ABI is a property of a specific target platform (architecture and possibly OS); every platform defines its own. Windows and Linux on x86_64 don't even use the same ABI (the width of "long" is different, for starters). But both platforms have C++ ABIs just as much as they have C ABIs. The problem with C++ ABIs is that C++ APIs tend to include much more substantial details in their headers. If you want to call a template or inline function, then you need a C++ compiler. Fundamentally, though, this is not any different from C macros -- a macro-heavy C API is going to require a C compiler to use.

StefanKarpinski 12y ago
It's certainly not cross-platform, but in practice you can call C libraries on a given platform the same way, regardless of which compiler generated them.
- kentonv 12y ago
  You can do that with C++ too -- assuming they are conforming to the platform ABI. On Linux, for example, all C++ compilers can call each other's code just fine. You may be thinking of the funny situation on Windows where GCC has historically flagrantly disregarded the platform C++ ABI and implemented its own instead. I assume this decision was made as a matter of practicality: The Cygwin people didn't have the resources to try to implement Microsoft's ABI, whereas porting over the existing code for the Linux C++ ABI was a lot easier. Also, MSVC tends to take much longer to implement new C++ language features than GCC does which means its ABI could often be missing things GCC needs. FWIW, Clang's port to Windows is taking the correct approach: they're implementing Microsoft's ABI, and will thus be able to link against MSVC-built C++ library. http://clang.llvm.org/docs/MSVCCompatibility.html http://clang.llvm.org/docs/MSVCCompatibility.html
  - hanumantmk 12y ago
    In all fairness, Microsoft breaks abi in the standard library with every single release. They do so deliberately to reserve the right to improve implementations over time. For some evidence: See an interesting reddit thread: http://www.reddit.com/r/cpp/comments/13zex3/can_vs2010_c_libsdlls_be_linked_into_a_vs2012_c/c78ott7 http://www.reddit.com/r/cpp/comments/13zex3/can_vs2010_c_lib... And a link to a msvc blog post which lists the sizes of various containers under various versions of MSVC: http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.a... Note that vector<int> on x64 shrunk from 48 to 24 bytes between VC9 SP1 and VC11. That's not an ABI, it's source compatibility.
    - frozenport 12y ago
      Its worse then that! The ABI is different for debug and release version of the same library resulting in crazy, crazy bugs.
    - kentonv 12y ago
      True, but that's a different level of ABI. Stefan is talking about the base language ABI, e.g. calling conventions, vtable layout, etc., which is what matters if you're trying to call C++ from another language. You're talking about the ABI of the standard library -- or, more accurately, any library that uses STL types in its interface (which probably disqualifies it from being called from another language anyway).
  - BlackAura 12y ago
    GCC didn't ignore the Windows C++ ABI. Windows doesn't have a platform C++ ABI. Microsoft consider MSVC's C++ ABI as being internal to the compiler. They don't guarantee that the ABI won't change between major versions, only that it won't change between minor updates. Either way, it is not considered to be part of Windows, unlike the C ABI. It's also not completely documented, so you'd have to reverse-engineer most of it if you wanted to be compatible. It's the platform's de-facto C++ ABI, certainly, and in practice it's somewhat stable, but hardly reliable or useful for anyone other than Microsoft. Other compilers and platforms used to have the same problem - each compiler had it's own ABI, and on platforms where one compiler was dominant, it basically became the de-facto standard, but there was no interoperability. That changed when pretty much every compiler (aside from MSVC) and OS (aside from Windows) adopted the Itanium C++ ABI, or a derivitive (like the ARM C++ ABI). The C++ standards organization have a draft proposal to have platform standard ABIs, specified and documented by the platform holder. This really only affects Windows, and would require Microsoft to define a C++ ABI for Windows. That would most likely mean documenting the MSVC ABI, and calling that the standard C++ ABI. Various Microsoft employees are pushing for it, so it might happen. The proposal was written by Herb Sutter, for example.
    - kentonv 12y ago
      Hmm, you got me. I had thought MSVC's C++ ABI was documented and intended to be used by other compilers, but sounds like I got that wrong. Still, as you say, it is the case that most other platforms do in fact have a C++ ABI (if belatedly).
- jamesaguilar 12y ago
  So why are you asking that the standards committee do it?

by kentonv 12y ago

StefanKarpinski 12y ago

It's certainly not cross-platform, but in practice you can call C libraries on a given platform the same way, regardless of which compiler generated them.

kentonv 12y ago
You can do that with C++ too -- assuming they are conforming to the platform ABI. On Linux, for example, all C++ compilers can call each other's code just fine. You may be thinking of the funny situation on Windows where GCC has historically flagrantly disregarded the platform C++ ABI and implemented its own instead. I assume this decision was made as a matter of practicality: The Cygwin people didn't have the resources to try to implement Microsoft's ABI, whereas porting over the existing code for the Linux C++ ABI was a lot easier. Also, MSVC tends to take much longer to implement new C++ language features than GCC does which means its ABI could often be missing things GCC needs. FWIW, Clang's port to Windows is taking the correct approach: they're implementing Microsoft's ABI, and will thus be able to link against MSVC-built C++ library. http://clang.llvm.org/docs/MSVCCompatibility.html http://clang.llvm.org/docs/MSVCCompatibility.html
- hanumantmk 12y ago
  In all fairness, Microsoft breaks abi in the standard library with every single release. They do so deliberately to reserve the right to improve implementations over time. For some evidence: See an interesting reddit thread: http://www.reddit.com/r/cpp/comments/13zex3/can_vs2010_c_libsdlls_be_linked_into_a_vs2012_c/c78ott7 http://www.reddit.com/r/cpp/comments/13zex3/can_vs2010_c_lib... And a link to a msvc blog post which lists the sizes of various containers under various versions of MSVC: http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.a... Note that vector<int> on x64 shrunk from 48 to 24 bytes between VC9 SP1 and VC11. That's not an ABI, it's source compatibility.
  - frozenport 12y ago
    Its worse then that! The ABI is different for debug and release version of the same library resulting in crazy, crazy bugs.
  - kentonv 12y ago
    True, but that's a different level of ABI. Stefan is talking about the base language ABI, e.g. calling conventions, vtable layout, etc., which is what matters if you're trying to call C++ from another language. You're talking about the ABI of the standard library -- or, more accurately, any library that uses STL types in its interface (which probably disqualifies it from being called from another language anyway).
- BlackAura 12y ago
  GCC didn't ignore the Windows C++ ABI. Windows doesn't have a platform C++ ABI. Microsoft consider MSVC's C++ ABI as being internal to the compiler. They don't guarantee that the ABI won't change between major versions, only that it won't change between minor updates. Either way, it is not considered to be part of Windows, unlike the C ABI. It's also not completely documented, so you'd have to reverse-engineer most of it if you wanted to be compatible. It's the platform's de-facto C++ ABI, certainly, and in practice it's somewhat stable, but hardly reliable or useful for anyone other than Microsoft. Other compilers and platforms used to have the same problem - each compiler had it's own ABI, and on platforms where one compiler was dominant, it basically became the de-facto standard, but there was no interoperability. That changed when pretty much every compiler (aside from MSVC) and OS (aside from Windows) adopted the Itanium C++ ABI, or a derivitive (like the ARM C++ ABI). The C++ standards organization have a draft proposal to have platform standard ABIs, specified and documented by the platform holder. This really only affects Windows, and would require Microsoft to define a C++ ABI for Windows. That would most likely mean documenting the MSVC ABI, and calling that the standard C++ ABI. Various Microsoft employees are pushing for it, so it might happen. The proposal was written by Herb Sutter, for example.
  - kentonv 12y ago
    Hmm, you got me. I had thought MSVC's C++ ABI was documented and intended to be used by other compilers, but sounds like I got that wrong. Still, as you say, it is the case that most other platforms do in fact have a C++ ABI (if belatedly).
jamesaguilar 12y ago
So why are you asking that the standards committee do it?