Can a compiled C++11 library (lib,dll,etc.) be linked in older C++ compilers?

Question

Could older C++ compilers (e.g. VS2008 and gcc3.4) link with external libraries written in C++11?

My thought is that the C++11 .lib files are just byte code at this stage, and it shouldn't bother the older compilers how it was generated, as long as it is somehow resolvable and callable.

I'm developing a small library whose API should still support C++03 users. So, looking forward, I'm wondering whether it's ok to implement my library using helpful features like std::unique_ptr and such, or do I have to just stick with boost::?

Answer 1

Provided your library only uses C++11 in its implementation and doesn't expose C++11 facilities or types publically, and especially if you use static linkage, then yes, this is possible and even standard.

Consider the common case where a library exposes a C-level interface (to be usable by the widest variety of clients) but which is internally implemented in C++. Clients linking against such a library need only worry about the public binary API (exported functions), which you'll have constrained to be legacy C/C++ for maximum compatibility. A Java program can link to C-level APIs which are internally implemented in C++. This does not mean that Java needs to "support C++". Similarly, an old-style C/C++ client can link to a C-level or C++-level API which internally uses some more avant-garde version of the C++ libs or any other libs. Two separate things: what's required to link to the library's interface, and what the library itself internally links to (or pulls in statically).

You simply don't expose clients of your library to the dependencies of your implementation.

If you can statically link your dependencies (C++11 or whatever else) into your library, this is clean and self-contained. The library is a true black box: nothing but bytecode. But even if your library links to your dependencies via "implicit dynamic" linkage (not to be confused with the explicity LoadLibrary/GetProcAddress kind and the similar methods on *nix and OS X), older clients should still be able to link to that library's public interface, even if they couldn't link to the libraries the library depends on.

Answer 2

Sounds like you want to write a new library for others to use, and that you would like to use C+11 as your implementation language. There are a number of issues to consider:

• by introducing a new version of C++ you will introduce the need to deploy the new C++ runtime libraries with your library, is that OK?
• you should not use new C+11 types in your public interface, otherwise they will not be able to call it.
• In general, you should avoid complex types, such as unique_ptr, even vector, etc. Unless you are distributing your library as source code, the layout of the objects in your library may differ from the layout in the client code. Stick with simple types that have no risk of object layout variations.