Question

I have a library I’m building which is targeted to be a DLL that is linked into the main solution.

This new DLL is quite complex and I’d like to make use of C++11 features, while the program that will link it most certainly does not. In fact, the main program is currently “cleanly” built using VS2008 and VS2010 (and i think GCC 4.3 for linux?).

What I propose:

Using VS2012 as the IDE and Intel C++ Compiler 2013 for compilation to .dll/.so – for linux – which, as I understand, is basically down to machine form (like an .exe).

While I’m familiar with using C++ to solve problems, I am not fluent in the fundamentals of compilation/linking, etc. Therefore, I’d like to ask the community if

1. This is possible
2. If it is possible, how easy is it (as simple as I described?) / what pitfalls or issues can I expect along the way (is it worth it)?

Areas of concern I anticipate:

• runtime libraries – I expect this to be the factor that derails this effort. I know nothing about them/how they work except that they might be a problem.
• Standard Library implementation differences – should it matter if it’s down to DLL form?
• threading conflicts – the dll threads and the main programs threads never modify the same data, and actually one of the main program’s threads will call the DLL functions.

Bonus: While the above is the route I expect to take, I’d ideally like to have this code open for intellisense, general viewing, etc (essentially for it to become a project in the main solution). Is there a way to specify different runtime libraries/compiler? Can this be done?

EDIT: The main reason for this bonus part is to eliminate the necessary “versioning” conflicts that will arise if the main program and this library are built separately.

NOTE: I’m not using C++11 just for the sake of being newer – strongly typed enums and cross-platform threading code will be huge bonuses for the library.

Answer 1

The question isn’t so much “Can an application use a library built with a different compiler ?” (The answer is yes.) but “What C++ features can be used in the public interface of a library built with another compiler and C++ standard library?”

On Windows, the answer is “almost none”. Interfaces (classes containing only virtual functions) are about it. No classes with data members. No exceptions. No runtime objects (like iostream instances or strings). No templates.

On Linux, the answer is “lots more but still not many”. Classes are ok, as long as the ODR is satisfied. Exceptions will work. Templates too, as long as the definition is exactly the same on both sides. But definitions of standard library types did change between C++03 and C++11, so you won’t for example be able to pass std::string or std::vector<int> objects between the application and library (both sides can use these features, but the same object can’t cross over).