Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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::?

share|improve this question
    
This question hints at the impossibility of what I'm attempting, but theirs is an application, whereas I'm developing an external library and the user of my library can code in either C++ or C++11. –  Konafa Aug 27 '12 at 3:38

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
Great! That's exactly what I was hoping for. I don't intend on using C++11 extensively, but it's nice to know I could pop in a lambda function or two in my hidden implementation when convenient. The C and Java analogies make sense. Thank you. –  Konafa Aug 28 '12 at 8:00

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.
share|improve this answer
    
Good points. I'll keep those in mind. Thanks. –  Konafa Aug 28 '12 at 7:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.