Using different C++ compilers and language versions when developing a single executable

Question

Our company will purchase a large and very complex piece of source code for satellite communications.

It is coded in C++ and we will code additions to it, also in C++, linking our code with the purchased code into a single executable unit.

• Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

• Is it necessary that we use the same version of C++ as the purchased code? If it is not using 2014, we _might_ want to use some features of it, but not if there might be some problems with mixing different versions.

In theory, of course, it ought not to matter, especially the language version, but it is conceivable that different versions of the compiler will generate different object code, potentially leading to timing differences, etc.

What should we be aware of?

Answer 1

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

It depends.

Compilers generate code targeting an ABI. Some are using a common ABI (for instance, if I'm not mistaken, both clang++ and g++ target to called Itanium ABI) and you should -- there may be bugs preventing you to do so -- be able to use the object code from both in a same program (assuming of course that you are using versions which target the same version of the ABI). The same is true between compiler version: some pay more attention to keep the same ABI between version than other. Obviously, they all need sometime an ABI change, and they may be forced to do so in an non compatible way. And obviously, some settings like the choice of a language standard may have an influence on the choice of the ABI.

Then there is the issue of the standard library. The compilers (or different versions of the same compiler) themselves may use the same ABI, and yet their standard library may be incompatible (and some compiler like clang++ may be usable with several standard libraries). Being able to make it works may depend on what is used in the interface.

In other words, you have to dig and find the information for the specific case you are in. As an starting point and an example of what kind of information you should look for, here is the information provided by libstdc++ (the library used by g++ and in some configuration by clang++)

Answer 2

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code? Is it necessary that we use the same version of C++ as the purchased code?

This is not mainly a technical question. It is a legal question about what you write in your contract. Make sure the software vendor provides you with a version guaranteed by him to be usable in your environment. Otherwise, there will always be a certain risk of running into trouble with a different compiler, compiler version, or language version.

This is especially important when you purchase the component or parts of it as closed source. Even if your supplier guarantees you can use the component with your current compiler environment, does he guarantee he will provide you with updates if you want to switch to a newer compiler version in the future? If you don't have access to the full source code, you will probably not have much luck in trying to solve any compatibility problems by yourself. That is why you should not just buy the software, but also think about a long term maintenance contract with your supplier.

Answer 3

Our company will purchase a large and very complex piece of source code for satellite communications. It is coded in C++ and we will code additions to it, also in C++, linking our code with the purchased code into a single executable unit.

Sounds good!

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

Speaking generally, no it is not necessary. The purpose of C++ is to act as an abstraction over these kinds of things, so a well-written C++ program will compile just as well on your toolchain as it did on the original author's, and the resulting program will have the same result. The performance may vary, because different compilers are good at different things, but the fundamental behaviour of the program should not change.

However, badly-written software may rely on implementation-specific behaviour, or even undefined behaviour. It may make assumptions about the built-in types, or about the platform's endianness. Even well-written software may have no choice but to rely on non-standard extensions that aren't available on your chosen toolchain, or it may do so because there was simply no need to spend time on adding a portability layer within the duration of the original project.

Ultimately, you will need to ask the author/vendor what the source code is written for. If they claim that it is specifically written against, say, Visual Studio 2015, and requires Windows API features, you should probably stick with that. But if they claim that it is portable, standard C++, then use whatever compiler you like. Make sure your purchase agreement includes a support arrangement so that you can get free help when it turns out the vendor was lying.

Is it necessary that we use the same version of C++ as the purchased code? If it is not using 2014, we might want to use some features of it, but not if there might be some problems with mixing different versions.

Probably. Maybe.

C++03 is forward-compatible for the most part so, if the code is C++03, then you're unlikely to have a problem. (Though some tweaks may be required.)

But features introduced in C++11 and C++14 are not backward-compatible so if the vendor used, say, C++11 lambdas, and you try to build their code in a C++03 compiler, that just won't work.

In theory, of course, it ought not to matter, especially the language version, but it is conceivable that different versions of the compiler will generate different object code, potentially leading to timing differences, etc.

Absolutely. If the code relies so much on a specific implementation in order to obtain expected results, then it is up to the vendor to be responsible and inform you of that. Since we live in the real world, I recommend being diligent and asking them first.

And I'll echo what others have said: ensure that you have some sort of support recourse, so that if they misrepresented any of the responses to these questions (whether intentionally or otherwise) you do not end up shouldering the resulting cost.

Answer 4

You don't link code, you link compiled object files.

In this case yes, using different C++ compilers (or even settings like debug/release builds), or different versions of them, or different (versions of) standard libraries when building parts that will interact at a binary level is highly likely to break the application if the parts communicate with each other using more than C APIs.

Features like containers or exceptions provide the same interface but, at a binary level, can be implemented in many different, incompatible ways.

Using a different compiler to compile the entire code is a different issue however. Questions to consider:

• What platform/architecture does the code target?
• For which standard was it written?
• Does it use any non-standard compiler features?
• Does the code contain hard-coded platform specific assumptions (like always considering that pointers occupy 2 bytes)?

There is also the risk that code may contain parts that result in undefined behavior. These could appear to be working fine when using one compiler but fail in mysterious ways when using a different one.

Answer 5

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

Well, switching compiler, can lead to some problems; currently in my company, we use Clang and MSVC, and we have error in one compiler that the other one doesn't mark as such.

Is it necessary that we use the same version of C++ as the purchased code? If it is not using 2014, we might want to use some features of it, but not if there might be some problems with mixing different versions.

It' not necessary, but of course you compiler should support the C++ version that you want to use. C++ guarantee retro compatibility starting from all version.

Answer 6

One big problem when changing compilers is undefined behaviour: If the code that you receive invokes undefined behaviour, then anything is possible - including that the code works just fine and passes all their tests when using their compiler, and goes terribly wrong with your compiler.

That's possible, but in that situation you might also run into problems if you change optimisation levels, use the next version of the same compiler and so on. So nothing you can avoid.