C vs C++, from the author of ZeroMQ

OffByOne

I haven't read the entire thread, but there is one major advantage of C over C++ that we have to deal with at work: C++ libraries (at least in VC++ land) can only be linked against using the same version of Visual Studio they were compiled with. Because of this, we have to ship C++ libraries that were compiled with all versions of Visual Studio from 2005 on to cover all our customers.

That's because of non-standardized name mangling.

If it makes sense in your particular case, you can wrap the C++ library API in extern "C" blocks. That will prevent name mangling.
The trade-off is you don't get the benefits that name mangling provides, like function overloading.

Bulb

@OffByOne said:

[quote="mott555, post:34, topic:48848]
C++ libraries (at least in VC++ land) can only be linked against using the same version of Visual Studio they were compiled with.

That's because of non-standardized name mangling.
[/quote]

It is not (only) about mangling. It is that there is no compatibility between the versions of standard runtime (msvcrNN). The gcc world is a bit better in that it does breaking ABI changes less often. Even on Windows where mingw by default sticks to msvcrt from Visual C++ 6.0, the version shipped with Windows (while the newer ones require “redistributable”. However it does break the ABI now and then too. C++ ABI is too complicated for it's own good.

dkf

There's the naming scheme, yes, but it's the functional parts of the ABI that are worse. Exception semantics, data structure packing, magic constants, all that sort of thing can be really awful if it changes. (The magic constant thing is also a problem with a C ABI, but at least it's relatively easy to avoid putting the structure sizes in there. C++ tends to bind such things into the ABI unless you remember to use PIMPL…)

powerlord

Since Visual C++ 6.0 is the one that broke one of the DLLs that shipped with applications and caused all sorts of application issues when VC++6 overwrote it with a version that removed a bunch of functions, I find their choice questionable at best.

There's a reason they're redistributables now... because someone at Microsoft fucked up badly and caused other applications, including iirc Microsoft Office, to stop working.

Part of the issue was that Visual C++ 4.2 through 6.0 all used msvrt42.dll (and other DLLs ending in 42).