There are two parts to the answer. Compatibility at the compiler level and compatibility at the linker level. Let's start with the former.
let's assume all headers were written in C++11
Using the same compiler means that the same standard library header and source files (the onces associated with the compiler) will be used irrespective of the target C++ standard. Therefore, the header files of the standard library are written to be compatible with all C++ versions supported by the compiler.
That said, if the compiler options used to compile a translation unit specify a particular C++ standard, then the any features that are only available in newer standards should not be accessible. This is done using the __cplusplus directive. See the vector source file for an interesting example of how it's used. Similarly, the compiler will reject any syntactic features offered by newer versions of the standard.
All of that means that your assumption can only apply to the header files you wrote. These header files can cause incompatibilities when included in different translation units targeting different C++ standards. This is discussed in Annex C of the C++ standard. There are 4 clauses, I'll only discuss the first one, and briefly mention the rest.
C.3.1 Clause 2: lexical conventions
Single quotes delimit a character literal in C++11, whereas they are digit separators in C++14 and C++17. Assume you have the following macro definition in one of the pure C++11 header files:
#define M(x, ...) __VA_ARGS__
// Maybe defined as a field in a template or a type.
int x[2] = { M(1'2,3'4) };
Consider two translation units that include the header file, but target C++11 and C++14, respectively. When targeting C++11, the comma within the quotes is not considered to be a parameter separator; there is only once parameter. Therefore, the code would be equivalent to:
int x[2] = { 0 }; // C++11
On the other hand, when targeting C++14, the single quotes are interpreted as digit separators. Therefore, the code would be equivalent to:
int x[2] = { 34, 0 }; // C++14 and C++17
The point here is that using single quotes in one of the pure C++11 header files can result in surprising bugs in the translation units that target C++14/17. Therefore, even if a header file is written in C++11, it has to be written carefully to ensure that it's compatible with later versions of the standard. The __cplusplus directive may be useful here.
The other three clauses from the standard include:
C.3.2 Clause 3: basic concepts
Change: New usual (non-placement) deallocator
Rationale: Required for sized deallocation.
Effect on original feature: Valid C++2011 code could declare a global placement allocation function and deallocation function as follows:
void operator new(std::size_t, std::size_t);
void operator delete(void*, std::size_t) noexcept;
In this International Standard, however, the declaration of operator
delete might match a predefined usual (non-placement) operator delete
(3.7.4). If so, the program is ill-formed, as it was for class member
allocation functions and deallocation functions (5.3.4).
C.3.3 Clause 7: declarations
Change: constexpr non-static member functions are not implicitly const
member functions.
Rationale: Necessary to allow constexpr member functions to mutate the
object.
Effect on original feature: Valid C++2011 code may fail to compile in this
International Standard.
For example, the following code is valid in C++2011 but invalid in
this International Standard because it declares the same member
function twice with different return types:
struct S {
constexpr const int &f();
int &f();
};
C.3.4 Clause 27: input/output library
Change: gets is not defined.
Rationale: Use of gets is considered dangerous.
Effect on original feature: Valid C++2011 code that uses the gets
function may fail to compile in this International Standard.
Potential incompatibilities between C++14 and C++17 are discussed in C.4. Since all the non-standard header files are written in C++11 (as specified in the question), these issues will not occur, so I will not mention them here.
Now I'll discuss compatibility at the linker level. In general, potential reasons for incompatibilities include the following:
- The format of the object files.
- Program startup and termination routines and the
main entry point.
- Whole program optimization (WPO).
If the format of the resulting object file depends on the target C++ standard, the linker must be able to link the different object files. In GCC, LLVM, and VC++, this is fortunately not the case. That is, the format of objects files is the same irrespective of the target standard, although it is highly dependent on the compiler itself. In fact, none of the linkers of GCC, LLVM, and VC++ require knowledge about the target C++ standard. This also means that we can link object files that are already compiled (statically linking the runtime).
If the program startup routine (the function that calls main) is different for different C++ standards and the different routines are not compatible with each other, then it would not be possible to link the object files. In GCC, LLVM, and VC++, this is fortunately not the case. In addition, the signature of the main function (and the restrictions that apply on it, see Section 3.6 of the standard) is the same in all C++ standards, so it doesn't matter in which translation unit it exists.
In general, WPO may not work well with object files compiled using different C++ standards. This depends on exactly which stages of the compiler require knowledge of the target standard and which stages don't and the impact that it has on inter-procedural optimizations that cross object files. Fortunately, GCC, LLVM, and VC++ are well designed and don't have this issue (not that I'm aware of).
Therefore, GCC, LLVM, and VC++ have been designed to enable binary compatibility across different versions of the C++ standard. This is not really a requirement of the standard itself though.
By the way, although the VC++ compiler offers the std switch, which enables you to target a particular version of the C++ standard, it does not support targeting C++11. The minimum version that can be specified is C++14, which is the default starting from Visual C++ 2013 Update 3. You could use an older version of VC++ to target C++11, but then you would have to use different VC++ compilers to compile different translation units that target different versions of the C++ standard, which would at the very least break WPO.
CAVEAT: My answer may not be complete or very precise.
std::stringrefers to can differ. – WedgeQString::toStdString()) were implemented inline in headers. I heard that this changed in recent versions, but I don't know how they handle it. – Wedge-std=flags. You are still in for a world of pain if you have a library compiled with an older g++ version. – Wedgestd::stringimplementation in libstdc++ is independent of the-stdmode used. This is an important property, precisely to support situations like the OP's. You can use the newstd::stringin C++03 code, and you can use the oldstd::stringin C++11 code (see the link in Matteo's later comment). – Ables