I understand that experimental features of a programming language should not be enabled by default so I welcome the flags -std=c++0x and -std=c++1y. However C++11 is now standard since a couple of years. Why compilers still require -std=c++11 to enable the support for its features?
C++11 has been standard for a couple of years, but a compiler isn't going to switch its default mode to C++11 until:
At an absolute minimum, C++11 support is complete in that compiler and the libraries it uses. And also stable, if the compiler writer has any concern at all for reliability.
Preferably, a major version number increase in the compiler, since C++11 is not fully backward-compatible to C++03.
Ideally, on a well-known schedule so that users can prepare for the change.
Basically, lots of people (and makefiles) rely on the compiler being a conforming C++03 compiler, or at least on its non-conformance being known. Since C++11 introduces new instances of non-conformance with C++03, the change is potentially traumatic.
Arguably anyone relying on C++03 should have specified an option to say so, and changes to the default mode would make no difference to them. But once you've documented your compiler's default, people are going to rely that, either intentionally or otherwise.
For gcc in particular, the 4.8.2 man page says that "support for C++11 is still experimental". So I think ultimately the answer to your question may be that it takes more than 2 years to properly implement C++11, even starting from all the work done with draft standards.
A small update. GCC 6.1 and above uses a C++14 mode by default [source].
Related
I have seen that the default standard in IDEs is usually not the newest released standard, not even the newest standard in the IDE.
For example JetBrains' Clion has C++20 and C++17 but the default option is C++14.
Is there a reason not to use the newest released standard?
As a general rule, use the latest standard if you can.
But, there are some reasons why you may in some situations choose to use an older one.
Your code makes use of features that changed behaviour in newer standards or were removed outright. If you don't have time to update your code, compiling for the older standard is reasonable.
Your tool-chain may not implement the new standard correctly. There could be known bugs that force you to stick to an older one.
You need to support multiple compilers on multiple platforms and not all combinations support the new standard yet.
You need to be binary compatible with code built by an older compiler for an older standard and you don't have the source to recompile it. In that case you may be forced to use the same old compiler and language standard to ensure ABI compatibility.
Internal company politics may mandate a specific version for arbitrary reasons.
Certification requirements may mandate use of a specific compiler and/or language version.
Familiarity with the new features may be low on your team, so using them may increase the risk of bugs.
Etc (I've seen all of the above happen in real life btw)..
In llvm's compiler implementation tutorial (e.g. here) llvm::make_unique is used. What is the reason they aren't using std::make_unique? I wasn't able to find any clear documentation on this.
TL;DR;
LLVM is written using C++11 conforming code while std::make_unique is a C++14 feature. So if they want make_unique they need to implement it.
Details
If we go to the LLVM Coding Standards the C++ Standard Versions section says:
LLVM, Clang, and LLD are currently written using C++11 conforming code, although we restrict ourselves to features which are available in the major toolchains supported as host compilers. The LLDB project is even more aggressive in the set of host compilers supported and thus uses still more features. Regardless of the supported features, code is expected to (when reasonable) be standard, portable, and modern C++11 code. We avoid unnecessary vendor-specific extensions, etc.
We can see from cppreference that std::make_unique is a C++14 feature. If they want to use make_unique then they can't use the std version.
We can see from a recent llvm-dev discussion that moving to C++14 is still an open subject.
Compiler vendors have been adopting C++11 features piecemeal, which was predictable, as many of them are not easily implemented.
The standard way for reporting which spec the compiler fully supports is via the __cplusplus predefined macro. However, major vendors are reporting __cplusplus = 199711L, meaning they are only fully supporting C++98 (eg. MSVC14). This (presumably) means that they do not fully support the C++11 spec, even though they may have implemented a lion's share of the functionality.
I would like to start using C++11 features, when they are available (and fallback to existing code when they are not). However, my code must support many compilers, including proprietary compilers which I may not have access to use. Is there any standard way to know which C++11 features are available from a compiler, without knowing specifically which compiler is being used? (if a compiler behaves in a non-standard way, then it is acceptable for the detection behavior to be incorrect).
NOTE: This question is a generalization of my question 'Availability of static_assert c++11', which was not very well received, because I think my motivation was misunderstood.
You might be interested in feature test macros, which enable you to test for specific C++11, C++14 or even C++17 features, such as __cpp_static_assert, __cpp_lib_make_unique or __cpp_variable_templates. Clang and GCC already support this, see a live demo.
g++/clang++ do not have C++11 enabled by default, not even the latest versions. Whenever you compile with g++ using -std=c++11, your macro __cplusplus will have the expected value.
VS seem to have all features enabled by default, thanks #Comic, but it is not updating the macro since it is not yet fully C++11 compliant.
As far as detecting "C++11 availability" for a generic compiler, I am not aware of any portable way of doing it, unless you check for the __cplusplus macro. But, as you observed, the macro may not be implemented for some compilers by default (as is the case for g++/clang++), or not implemented at all (VS). Your only choice at this stage seem to be an external tool like CMake, which can detect the compiler, and conditional on the compiler type CMake can then define some macro which you can check in your code to enable C++11.
I think many of the C++11 features are available on GCC 4.8 also. Compile your program with -std=c++11 option.
I think some of the C++11 features were in GCC 4.6.3 as well. Compile option to enable it -std=c++0x .
I know those flags are for C++11 in Eclipse.
But I don't know what is difference and which one is more preferred.
It seems that they both are working with C++11 normally.
You should prefer -std=c++11.
(Note: I assume -std=c++11x is a typo in your question)
The old -std=c++0x is only needed for older compiler versions that did not support -std=c++11 and they chose that name to express the preliminary and unstable nature of features (and the ABI) of the then upcoming C++11 (and when it was still unclear whether that would eventually become C++10 or C++12). They changes some of the details adapting to the changing working drafts of the standard at the time before the C++11 standard was officially released.
If your compiler supports -std=c++11, there is no reason to use -std=c++0x. Concerning compatibility: There might even be differences and incompatibilities, but these are not just bound to the use of -std=c++0x, but to specific versions of the compiler. When the compiler supports both, they should be identical.
C++ and C Standards are usually named after the year they are published in, which makes it easier to remember by.
For example, in C++, the original Standard was published in 1998, so we talk about C++98, and when we refer to its first correction, published in 2003, we talk about C++03.
It had been purported that the next Standard after would be done for 2008, but since it was uncertain, it was dubbed C++0x, where the x stood for either 8 or 9. In practice though, as we all know, the planning shifted and so we end-up with C++11.
Still, for the next version (C++1x), Bjarne Stroustrup stated his intent to do it in 5 years (so about 2016). For now, there are changes envisionned to the core language (concepts, modules and garbage collection), and the focus seems to be more on extending the library (filesystem for example), but it's still early so who knows!
I read that MSVC is not fully compilant to the ISO C++ standard (German Wikipedia and several Tech sites).
In which ways isn't C++ standards compilant?
Actually no compiler is fully standard compliant, but MSVC gained its reputation for implementing everything that the standard didn't explicitly state in a profoundly stupid and unportable way.
I would say that the latest releases are relatively good when it comes to standard support, at least when you try to compile standard compliant code in MSVC.
But MSVC is still very lazy when it comes to pointing out code, that doesn't follow C++ standard (even on the strictest settings), so porting code from MSVC to anything else is always huge pain.
But there are still many flaws/bugs/etc... for example unlike GCC, MSVC will allow you to modify a set/map iterator.
Well, I think it depends on your definition of compliant. There are several things that have not been implemented in the standard by almost any compiler company (several suggestion from the 98ish revision and template definitions in implementation files). MS has extended the language somewhat also. However, if you write code in basic c++ without the MS extensions or libraries, it will most likely be portable to another compiler with very, very minimal work (if any).
It's been a while since I've looked into this, but the C++ library that I work on uses quite a lot of template metaprogramming (nothing horribly complicated, but still beyond the simplest levels), and for quite a while it wouldn't compile under MSVC due to bugs or missing functionality in their template resolution code, although it works fine in GCC and Intel's C++ compiler.
I don't think we've tried it in the latest couple of revisions of MSVC, so they may have fixed those bugs.
Also, IIRC, MSVC does not turn on run-time type information support by default (for performance reasons), and support for that is required by the C++ standard.