5 ms·
Please stop adding features to C++ and standardize an ABI already. The lack of an ABI is why it's impossible to call C++ libraries without an entire C++ compile
by StefanKarpinski 12y ago
Please stop adding features to C++ and standardize an ABI already. The lack of an ABI is why it's impossible to call C++ libraries without an entire C++ compiler – and it generally requires generating mountains of wrapper code a la SWIG – which is then called with the C ABI. The lack of an ABI is why dynamic libraries use C for writing extensions instead of C++: C++ can literally only be called by C++ (and in fact only by the same C++ compiler).
- jamesaguilar 12y agoIt's not really the responsibility of the standard committee, right? C also has no standard ABI.
- StefanKarpinski 12y agoC absolutely has an ABI – you do not need a C compiler to call a C library.
- mappu 12y agoYou 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 agoThe C ABI is a property of the platform, not the language itself.
- kibwen 12y agoBut not a standardized one, I think. Merely a few widely-used calling conventions (e.g. stdcall, cdecl). Or am I misusing terminology?
- kentonv 12y agoNonsense. 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 agoIt'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 agoYou 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 agoIn 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.
- spacemanmatt 12y agoA proposal for C++ to stop being such a moving target.
- jevinskie 12y agoLuckily, this has already been proposed: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n402... I really hope it makes it into the language. A stable API for external functions and whatever ABI you want for internal functions.
- binarycrusader 12y agoThere is an ABI most C++ vendors conform to already: http://www.swag.uwaterloo.ca/acd/docs/ItaniumC++ABI.htm Almost every major vendor has been working towards this for a long time now. Microsoft of course remains "special". Regardless, the C++ standards committee did look at creating a portable C++ ABI in May 2014: https://isocpp.org/blog/2014/05/n4028
- Ezodev 12y agoOh, of course they cant do these simultaniously, right? Or features are wrong? What's exactly wrong with this feature? Its improvement.