3 ms·

It's not really the responsibility of the standard committee, right? C also has no standard ABI.

• StefanKarpinski 12y ago
  C absolutely has an ABI – you do not need a C compiler to call a C library.
  • mappu 12y ago
    You still need to know whether the C library expects stdcall, pascal, cdecl, several variants of fastcall, as well as a dozen less popular conventions - and that's just on x86. Stdcall convention in C also often does some name mangling (leading underscore, trailing @ and the number of bytes on stack) but not always. Also a C++ ABI would need to extend beyond simple calling conventions and also specify fixed behaviour of vtables, which i think compiler authors might balk at.
  • dbaupp 12y ago
    The C ABI is a property of the platform, not the language itself.
  • kibwen 12y ago
    But not a standardized one, I think. Merely a few widely-used calling conventions (e.g. stdcall, cdecl). Or am I misusing terminology?
  • 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.