Following link, I'm wondering if there're some side effects of enabling C++0x in GCC.
According to gcc: "GCC's support for C++0x is experimental".
What I'm afraid of is that for example compiler will generate some code differently or standard library uses some C++0x feature which is broken in gcc.
So if I don't explicitly use any of C++0x features, may it break my existing code?
The C++0x support has been, and is under heavy development. One thing this means is that bugs get fixed quickly, another thing it means is that there might be small bugs present. I say small, because of two reasons:
libstdc++ has not been rewritten from scratch, so all the old elements are just as stable as it was before any of this c++0x was available, if not more stable, because of several years of bug fixes.
There's corner cases in the new/old Standard that haven't yet been ironed out. Are these the runtime quirks you talk about? No. C++0x support has been under development for 4 releases now, don't worry.
Most of the impact from that flag will be felt in the new language features, the library features like move constructors and std::thread (on posix platforms) don't affect code not using them.
Bottom line, experimental is too strict a word in daily production. The standard has changed in the three/four years GCC has been working on support. Old revisions of c++0x will be broken in a newer GCC, but that's a good thing. C++0x is finished as far as the non-paying-for-a-pdf-world is concerned, so no breaking changes should be added. Decide if you want the new stuff or not beforehand, because you won't be able to jsut switch it off once you've gotten used to using it.
Usually, it won't break your source code, but you may include (even without noticing it or knowing it) C++0x idioms that will compile because of these features enabled, but won't compile in a strict C++ compiler (for instance, in C++0x you can use >> as a template of template terminator, but not in C++, so if you forget to separate it by a space, you will have problems when you try to compile this code in a C++ compiler).
R-Value references/moves is a feature which can have a huge impact on how the compiler does optimizations and such. Even if you don't use move in your own code, the STD includes will automatically switch to their new versions which include move ctors/assignment.
There are some circumstances which allow the compiler to create move constructors/assignment operators implicitly for user defined classes. These rules changed a few times during the standardization process (I don't even know what the current rules are). So, depending on the exact version of your compiler it could be using a set of rules for generating these implicit functions that isn't even in the latest version of the standard.
Most of the other major C++0x changes don't have big run-time impact, they are mostly compile time (constexpr, string literals, varadic templates) or syntax helpers (foreach, auto, initializer lists).
I originally wrote the question you link because of (in my opinion) a very big issue as described here. Basically, overloading a function with shared_ptr to a const type was not recognized by the compiler. That's a huge flaw in my opinion. It's been fixed from GCC 4.5 to GCC 4.6, but it serves as an example of a big bug that's still around in the default installation of GCC in ubuntu, for example. So while bugs are fixed quickly, there still might be bugs, and you may waste a weekend looking for the source and solution of those bugs.
My recommendation, based on this personal experience, is to avoid C++0x until the word "experimental" is removed from the description of GCC's support of C++0x or until you actually need any of the C++0x features to a degree that an alternative implementation would significantly sacrifice good design.
