1

Ok, I know this sounds like a broken question, but let me explain before the downvotes start: we are using C++11 as a baseline for our development (targeting several platforms). Recently a few changes needed to be done in our codebase and suddenly the need for some C++17 features crawled in.

All is fine till now, on our developer platform all compiles nicely, but on one of the continuous integration platforms (Ubuntu 18.04) we have got some errors, like:

/usr/include/ev++.h:355:46: error: ISO C++1z does not allow dynamic exception specifications dynamic_loop (unsigned int flags = AUTO) throw (bad_loop)

(c++1z dynamic exception specification error gives a good explanation why this happens and also offers some hacks on how to make it disappear)

But I started thinking (theoretically only, of course) that would it be possible that we specify some portions of a source file to be compiled with code conforming to C++11 and other parts with code conforming to C++17?

(And just to clarify: No, we don't want to upgrade, and yes, we have solved the problem, again, I am just interested in a theoretical approach)

Tony Tannous
  • 14,154
  • 10
  • 50
  • 86
Ferenc Deak
  • 34,348
  • 17
  • 99
  • 167
  • 3
    *"on our developer platform all compiles nicely, but on one of the continuous integration platforms (Ubuntu 18.04) we have got some errors"* I _strongly_ suggest you make the environment homogeneous. There's a potential for _lots_ of very subtle issues if your CI machines are different from the developer environment. Especially the compiler and standard library versions should be the exact same. Using libraries from package managers is also a recipe for subtle issues (except, maybe, glibc). – dyp Feb 17 '21 at 08:49
  • 7
    No, it is not possible to use different C++ standards in different areas of the *same translation unit*. You should be able to use different C++ standards for *different translation units*, though. Refractor your code accordingly. – Remy Lebeau Feb 17 '21 at 08:50
  • 1
    you can put half of the file in a `#ifdef COMPILE_THIS` and the other half in a `#ifdef NOW_COMPILE_THAT`, thats basically the same as refactoring into two files, just a lot messier – 463035818_is_not_an_ai Feb 17 '21 at 08:53
  • For this very problem - just remove throw (bad_loop) or comment it: `// throw (bad_loop)`. In general - it seems you need to have config.hpp that defines macros for all compilers used by your project - with defining macros. For example - look at boost config.hpp – PiotrNycz Feb 17 '21 at 09:08
  • In broad sense, from portability point of view, your request looks impossible. C++ do not guarantee ABI compatibility between standards. Technically even function call from c++17 fragment in your otherwise c++11 code could generate different mangled symbol, so this won't link. If you use c++17 stl method and link against c++11 lib you might end up with missing symbol, etc. That is if we are talking about purely theoretical possibilities. In practice gcc is ABI compatible between standards starting from some version of compiler (5.0?). – Konstantin Stupnik Feb 17 '21 at 09:54

1 Answers1

1

In theory-theory it would be possible. Compiling different parts of file with different standards is effectivelly splitting the file and using different backend for every of these parts. It should not be that hard. But there is one big caveat - ABI compatibility. When you realize that linking object files compiled with different standards is often not possible, you see this whole idea is a landmine. The compiler would have to either keep the ABI stable (which would be nice but with the amount of changes made with every standard, keeping the ABI compatible between them would be a nightmare) or somehow translate the ABIs of different standards (this would also be nightmarish I suppose). Even now the most popular way to keep the ABI problems 'in check' is using extern "C" to avoid all fuss.

So the answer is - it would be possible in theory but the practical implications of such choice would be so dramatic that it is not worth it.

bartop
  • 9,971
  • 1
  • 23
  • 54