https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #2 from Niels Möller <nisse at lysator dot liu.se> --- (In reply to Jonathan Wakely from comment #1) > The ABI dictates the calling conventions and there's certainly nothing that > libstdc++ can do about it. My impression was that C++ ABI is under the control of compiler and C++ standard library, and that there is no such thing as a standard C++ ABI. As evidenced by the (rare) ABI breaks in libstdc++, and the difficulty of linking C++ objects compiled with different C++ compilers (e.g, g++ and clang++). If ABI standard + language spec nails down, e.g., rules on when to pass a C++ object by invisible reference, but doesn't nail down the ABI of std::string, then the C++ specifics of the ABI standard is a bit pointless, imo. But I understand my opinion doesn't carry much weight on that... So if it's really not feasible to improve the situation at all for gnu/linux x86_64 elf targets, *please* try to keep std::unique_ptr in mind when involved in ABI design for other targets. For specific types defined by the GNU standard C++ library, it may also be possible to add any needed G++ specific attributes in library headers to tell the compiler to depart from the "standard" ABI. > In any case, how common is it to have a pointless non-inline baz function > which does nothing but forward to another non-inline function? In my experience (mainly from working on the webrtc.org code, where implementation inheritance is discouraged), it's common with implementations of interface classes consisting of almost trivial implementations of the interface's virtual functions, which only setup the correct arguments for calling a non-inlined (and possibly virtual) method on some member to do the real work.
