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!
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)..
Can bool datatype be used in C++ and can portability still be ensured?
There are discussions about this partially in other posts, but does not specifically discuss portability.
I would like to know if I can use bool and be sure it will compile in most systems (say 99%), if not all systems.
bool is a built-in type so it is as portable as the C++ language itself
bool is a builtin type since the first C++ standard (C++98), so if you have a compiler that conforms to any C++ standard (and arguably, any compiler from the last 20 years) you should be set.
As for pre-standard C++, looking around it seems that, on PC compilers, it made its appearance around 1996-1997 (Visual C++ 5, Borland C++ 5); indeed, GotW #26 mentions that bool is "the only builtin datatype to be added to C++ since [Stroutroup's] Annotated C++ Reference Manual" (1990), so it's reasonable to deduce that it was born somewhere between 1990 and 1996. Reading around the web 1993 is thrown around quite often as "birth date" for bool in C++, but I couldn't find a single reliable reference for it.
Although you can still find obsolete pages (mostly from university courses) that explain how to workaround the absence of bool in old compilers, nowadays there are no compatibility issues using it, unless you are forced to use really ancient toolchains (I'm looking at you, university courses which recommend Turbo C++ in 2018).
Maybe you got confused with C, where bool appeared only in C99?
Was bool available in pre-standard C++ (like Cfront)?
Looking at the sources of Cfront 3.0.3 (1994, although the original 3.0 was released in 1991), bool is thrown around quite a bit indeed, especially in standard headers such as basic_string.h.
As for its definition, there is an insane mix of typedef char bool; (but inside an #ifdef CFRONT_COMPATIBLE_LUCENT, so maybe it's just a compatibility definition? And WTF, the copyright date is 1996?), #define bool char, enum bool { false, true };, as well as a typedef int bool; in a promisingly-named std_bool.h header (which however has copyright date 1996 as well!).
Looking at the lexer and the parser I couldn't find mentions of bool, although the demangler cites it as a fundamental type, so there is some evidence that somebody thought it was (or, was going to be) a builtin.
Still, while its precise definition is a bit of a blur, as said above something named bool with true and false values was indeed available and used in the standard library, so, if you plan to compile your code with Cfront 3.0, bool is probably going to be the least of your concerns. :-)
Incidentally, this trip down ancient C++ brings some sadness as well: Cfront 3.0 shipped with a C++ regex library, something that we had to wait for C++11 to get back again (and which remained segfault-level broken for quite some more years in libstdc++).
Note that if you are worried about storage portability (serialization) then bool is not a particularly portable type, the size is not tied down (indeed it is hardly ever the same size as 'char').
This despite the fact that bool has been in c++ as long as the language has been standardized.
C++ does not mean much (it is more a family of related languages, than a single one). You need to target a specific C++ standard. Consider at least C++11 (but don't bother about older standards, which probably mentioned bool also), and if possible C++14.
Then bool is part of C++11 (and also of later standards like C++14 or C++17). Check by reading n3337. It was also part of C++98 but you should not care.
(Notice that C++ has changed a lot since C++11 included, this is why I don't recommend using older standards like C++98; and portability matters only when referring to a particular standard; it usually does not make sense to write code portable to all of C++98, C++11, C++17, C++20)
If you want to code for an obsolete standard like C++98 something which could compile with a later standard-conforming compiler (e.g. some C++17 compatible one) you should ask a different question. bool is then not an issue, but you have many other (more important) ones.
The question of what is the C++ standard supported on most platforms is a very different one. If you can afford using recent compilers (e.g. if you can install recent versions of GCC or Clang) I would bet on C++11.
You'll certainly be able to find, perhaps in some museum, an obsolete computer which has a C++98 compiler but not a C++11 one. You could even find computers without C++ compilers (or even without any compilers).
Certainly, an old Sun3/60 from 1987 in a museum accepts a C++ dialect (perhaps some Cfront) very different of the several dialects of C++ accepted by GCC 8 on my Linux desktop.
What you want to code against is a standard (such as C++11, which, like C++98, C++14, C++17 also mentions bool). This ensures portability to other implementations of the same standard. Of course C++98, C++11, C++14, C++17 all mention bool; but if you want to code against several C++ standards (and this could be difficult) you need a lot of care (probably using some preprocessor conditionals to provide different code for different C++ standards when that is needed).
The Filesystem Technical Specification (TS) has recently been merged into the C++17 standard.
The same TS is also available for C++14, but in this case it's technically only "experimental". However the fact that it's been approved for C++17 makes me think it's mature enough and that it can be used safely.
When working on a C++14 project that will most likely be upgraded to C++ 17 in the future, and assuming the compiler I use supports it on both versions, would you advise against using the "experimental" TS, considering that it will officially be part of the next standard?
My question of course extends to any TS that has been accepted in a future C++ version and that is available for earlier standards.
The real question is whether or not somebody's implemented it, not whether or not it's been approved/merged/whatever of some arbitrary document. Features can be excised, added or modified at any point in time of the standardization process. We've seen things get cut from C++14 right before release and also things that couldn't make it that were later amended. Vendors rely on specific versions of documents when implementing features and so the only surefire way is to consult the documentation of whatever compiler you're using.
Actual implementations can contains features that are not in the current standard, and can have flaws in other features that are defined in the standard or even can fail to implement specific parts - Microsoft was know to let parts of the standard unimplemented.
But if a compiler supports a feature, and if that feature is part of next standard, there is little risk if any that it will disappear in a future version of that particular compiler.
Simply, some other compiler may not implement it as soon as it is approved in standard, but you know whether it is a problem in you specific use case.
Is it safe to use a C++ Technical Specifications approved for a future standard in a earlier standard?
It depends on what you mean by "safe"
Is it portable?
No.
Does it work?
You need to check the release notes of your toolset's version, and the release notes of your standard library's version (they may be different).
Will it work tomorrow?
Who knows?
Should I invest time in code that assumes it works?
probably not.
In summary, the answer is "no".
Use the boost version until the standard is published and your compiler and standard library conforms to it.
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].
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.