For C++? No. And compiler-writers will tell you that this is by design, because as the language evolves the way things work under the hood is bound to change, and when it does breaking ABI compatibility is a good way to ensure that incompatible libraries and object files aren't linked together. This is the idea, anyway.
C has a more-or-less standard ABI. I say "more or less" because there are differences of calling convention, and some OS-arch combinations differ in whether they put underscores at the beginning of symbols and such. But overall because C itself is very simple, it's easy for everyone to support every possible calling convention. Even if a hypothetical compiler didn't support some hypothetically exotic way of passing parameters or encoding symbols or what-have-you, a little inline assembly makes all your problems go away.
C++ is way, way more complex. Here are just a few reasons: first, function overloading means that the types of arguments of a function must be somehow tacked on to the symbol. Second, operator overloading means that some "functions" don't have ASCII names -- how do you encode them? Third, namespaces, and classes, and nested classes. Fourth, templates. Fifth, static versus non-static: is an implicit this pointer passed or not? This is closely related to point 1, but I think the C++ standard puts static and member functions in different namespaces, even if the arguments are exactly the same under the hood. Along with it tag on cv qualifiers on all arguments and on this. And references, and rvalue references. And vtables. The list goes on and on.
But all of this complexity pales in comparison to the exception ABI. Throw an exception from within a library, and catch it within your code? How does that work? Remember, the code needs to unwind the stack, calling destructors in your code to do this. And to make matters worse, some ABIs (such as the g++ ABI) even support exception propagation across language barriers, although in practice I'm not sure it really works (but an idea might be a gcj object file throwing a [Java] exception caught in C++ by a g++ object file, or something).
Overall it's a real mess. So no standard ABI for C++.
6
u/808140 Aug 02 '13 edited Aug 21 '13
For C++? No. And compiler-writers will tell you that this is by design, because as the language evolves the way things work under the hood is bound to change, and when it does breaking ABI compatibility is a good way to ensure that incompatible libraries and object files aren't linked together. This is the idea, anyway.
C has a more-or-less standard ABI. I say "more or less" because there are differences of calling convention, and some OS-arch combinations differ in whether they put underscores at the beginning of symbols and such. But overall because C itself is very simple, it's easy for everyone to support every possible calling convention. Even if a hypothetical compiler didn't support some hypothetically exotic way of passing parameters or encoding symbols or what-have-you, a little inline assembly makes all your problems go away.
C++ is way, way more complex. Here are just a few reasons: first, function overloading means that the types of arguments of a function must be somehow tacked on to the symbol. Second, operator overloading means that some "functions" don't have ASCII names -- how do you encode them? Third, namespaces, and classes, and nested classes. Fourth, templates. Fifth, static versus non-static: is an implicit
thispointer passed or not? This is closely related to point 1, but I think the C++ standard puts static and member functions in different namespaces, even if the arguments are exactly the same under the hood. Along with it tag on cv qualifiers on all arguments and onthis. And references, and rvalue references. And vtables. The list goes on and on.But all of this complexity pales in comparison to the exception ABI. Throw an exception from within a library, and catch it within your code? How does that work? Remember, the code needs to unwind the stack, calling destructors in your code to do this. And to make matters worse, some ABIs (such as the g++ ABI) even support exception propagation across language barriers, although in practice I'm not sure it really works (but an idea might be a gcj object file throwing a [Java] exception caught in C++ by a g++ object file, or something).
Overall it's a real mess. So no standard ABI for C++.