Search code examples
c++c++11clang

Is there a risk in changing the C++ dialect to C++11, but keeping the standard library non C++11 on XCode4?

Let's say I have a cross platform (Win & Mac) production code base that does not use any C++11.

Let's say that the compiler options on mac have been changed to use the C++11 language dialect, but without the C++11 standard library.

I have tried googling around to understand the possible implications, but am coming up empty.

My questions are:

  1. What does changing the language dialect in clang even mean?
  2. What is the risk with doing something like this?
Solution

  • I don't use XCode, but I imagine if they're shipping a (presumably incomplete but getting there) C++11 mode for clang, then they're also shipping a (presumably incomplete but getting there) C++11 standard library. And testing them together. So your situation shouldn't arise, but assuming it has anyway:

    1. Formally it doesn't mean anything, because the standard doesn't recognize any way of mixing and matching "language" and "libraries". It's up to your compiler what it thinks it means. Probably what it means is that new "language features" like rvalue references, lambdas, etc, become available, but new classes and functions in namespace std don't.

    2. Main risk is probably that you're no longer programming to a recognized standard, you're programming to a possibly under-documented thing invented by your compiler. If the compiler says that in C++11 mode it needs a C++11 standard library, and you supply it with a C++03 standard library, then you don't even have the compiler docs to blame -- anything might happen, you broke it, your fault.

    Quite aside from the risk of this funny combination, there are small risks in taking a C++03 code base and compiling it using any C++11 compiler. There are some code constructs in C++03 that compile as C++11 but with subtly (or grossly) different meaning.

    For example it is just about possible to write a class in C++03 that will break when used in C++11, because C++11 will generate a move constructor that doesn't do the right thing. Sometimes you have to replace a compiler-generated copy constructor that doesn't do the right thing (Rule of Three), and while C++11 ensures that in those "normal" situations the move constructor is suppressed, there are some odd edge cases. Unfortunately I can't remember them at the moment.

    The C++11 standard lists some incompatibilities between C++11 and C++03. You'd hope all, but you know how it is. The list is in appendix C. It starts with:

    Valid C++ 2003 code may fail to compile or produce different results in this International Standard. Specifically, macros named R, u8, u8R, u, uR, U, UR, or LR will not be expanded when adjacent to a string literal but will be interpreted as part of the string literal.

    and it doesn't get much more riveting reading from there. But it's basically a list of things that, if they appear in your C++03 code base, need changing in order to get equivalent C++11.