[aidenn0]

If you use the same compiler, ABI is a non-issue.

If you want to distribute dynamic-link binaries for windows, use MSVC.

If you want to distribute dynamic-link binaries for OS X, use Xcode.

If you want to distribute dynamic-link binaries for linux, you are SOL regardless of whether or not you are using C++, but if you use the same compiler and flags that the latest LTS version of Ubuntu uses, then it will work on Ubuntu, and will be made to work anywhere that Steam works.

It used to be that there were at least two C++ compilers for each *nix (typically GNU and something cfront based), so ABI was a much bigger deal.

When "Modern C++ Design" came out, famously none of the compilers could correctly compile all of the sample code. Since then things are much better; not that all compilers are bug-free of course, but they are sufficiently good enough that if you report a bug, you can expect it to be fixed.

[EDIT]

"Don't use STL Types in your interfaces" is not advice I've heard in like 15 years; I more often hear "If you're using a C array instead of a Vector, you're doing it wrong"

"Don't throw exceptions across module boundaries" seems similarly odd. Unless your constructors are inlined, no modern code-base will follow that rule because RAII relies so strongly on exceptions.

There are coding styles that are opposed to exceptions as part of an external interface, but that's due to exceptions not being checked as part of the type system, and is not what I would call a majority opinion.

[elderK]

Thanks for the response.

To clarify "module boundaries", I mean "separate shared objects."

As for Linux, I'm not too concerned with creating a single binary that works for all distributions.

I'm more concerned with someone being able to build a set of shared libraries on their distribution of choice and those shared libraries being able to interact naturally regardless of which compiler s/he uses to build each of them.

Say, LibA is built using LLVM. LibB is built using G++ and LibC is built using ICC.

LibA defines several classes. LibB creates some subtypes. LibC instantiates types from both LibA and LibB.

All the functions present in LibA, LibB, LibC make use of STL types such as std::string, std::vector, etc. Some may throw exceptions, whatever.

With respect to MSVC, I've read that compatibility between Debug and Release builds is kind of suspect, especially if you're using STL types. Not to mention differences in MSVC version. Is this still a concern?

[aidenn0]

> I'm more concerned with someone being able to build a set of shared libraries on their distribution of choice and those shared libraries being able to interact naturally regardless of which compiler s/he uses to build each of them.

Sorry, but this is an unreasonable standard. Literally no language, including C supports this. With C it only works inasmuch as the C compiler authors work really hard to make it works, and even then it sometimes breaks (if your compiler inlines a call to malloc, and you free a pointer compiled with a different C Compiler that inlined a different malloc implementation, it can break horribly. Yes I've seen this happen.)

Some languages support cross-version linking (or whatever the language's equivalent of "linking" is), but I'm not aware of any that specify a complete ABI for unrelated implementations to support. IPC libraries do typically support this though.

[edit]

I don't want to go on a shared-library rant, but I am fairly strongly opposed to them (except perhaps in cases like how nixos manages it). You can take a statically linked binary from 1997 and run it unmodified on your linux machine today. It is a virtual guarantee that any dynamically-linked binary more than 2 years old will not work correctly. Linus puts a huge amount of effort into backwards compatibility, and it is completely destroyed by dynamic linking.

[overgard]

> If you use the same compiler, ABI is a non-issue

And yet... microsoft releases a new compiler every two years or so, and not every library you use is going to update at the same time. This is a huge frustration for a lot of people.

I write c++ professionally and I've seen people waste weeks on these things, and most the libraries we wrote had plain c interfaces because being able to use other languages to call into the code was important and c++ is a nightmare with that.

[aidenn0]

Yeah, MSVC breaking ABI is somewhat annoying, but I am also used to keeping the most recent half-dozen MSVC's installed.

VS 6.0 is getting very hard to source legally these days, and I wish MS made it easier to get.

As far as having high-level languages call directly into C++, yes that's quite a pain (nearly impossible without something like https://github.com/rpav/c2ffi). Note also that calling into non-C ABI functions in any language is hard (and most HLLs don't support anything like extern "C" to make it easy).