This is not a question about which c++11 features are supported by gcc (I believe since 4.8 the c++11 support is pretty complete), but if there are any known problems in using them in production code.
The reason I'm asking is that I had a look at the manual for gcc5.2 and in the section "Language Standards Supported by GCC" it reads:
[...] most of which have been implemented in an experimental C++11 mode in GCC.
That word experimental got me a little worried, but on the other hand, c++14 isn't even mentioned, although I believe GCC supports all of those features, too.
So is this just an oversight in the documentation or are there really any valid concerns against using c++11 features in production code that will be compiled with gcc5.2 (4.8)?
Looks like actually it's experimental only on words. In gcc 6.0 it will not be experimental more.
The default mode for C++ is now -std=gnu++14 instead of -std=gnu++98.
But now, default mode is gnu++98 and so, it's experimental (one of the reasons, why we don't use C++11/C++14 now).
Related
I have a question about state of the art of the STM ( Software Transactional Memory ) in C++.
I read on cppreference site (transactional_memory) that this is an experimental feature, but it also say that the page is under costruction, so my question is:
Is this feature now supported by the standard? (example c++17 or c++20)
If not yet, the cppreference page says:
This technical specification is supported by GCC as of version 6.1 (requires -fgnu-tm to enable). An older variant of this specification was supported in GCC as of 4.7.
Is this feature supported also by newer GCC versions?
The phrases "STM", "software" and "transactional" do not occur in the standard (working draft, N4849, 2020-01-14). So I think it's safe to say that it's not supported by the standard.
As for GCC, man g++ for version 10.2.0 says:
-fgnu-tm
When the option -fgnu-tm is specified, the compiler generates code for the Linux variant of Intel's current Transactional Memory ABI specification document (Revision 1.1, May 6 2009). This is an experimental feature whose interface may change in future versions of GCC, as the official specification changes. Please note that not all architectures are supported for this feature.
For more information on GCC's support for transactional memory,
Note that the transactional memory feature is not supported with non-call exceptions (-fnon-call-exceptions).
The second paragraph really ends mid-sentence. Maybe they meant to link to the GCC wiki page on TransactionalMemory.
In any case, it seems like support in GCC has been present in some form or other since version 4.7.
First of all, C++17 changes are listed in this post. Today I downloaded clang to check if it was complete for C++17 (as gcc hasn't implemented everything yet), and here you can read:
Clang 5 and later implement all the features of the C++ 2017 Draft International Standard.
You can use Clang in C++17 mode with the -std=c++17 option (use -std=c++1z in Clang 4 and earlier).
Then, I assume that all features of C++17 have been added in clang 5.0, but checking all of them, I couldn't find the extensions for parallelism of stl algorithms and so on. I tried adding the header <execution> to test the new feature, but nothing seems to work.
I'm suspencting that this feature "maybe" won't be available, but I'm not sure because there's almost no information about it.
I think Intel implemented something in its compiler, but I'm not really into it since I use Linux.
Are extensions for parallelism going to be available for the new C++17 Standard?
Yes, extensions for parallelism have been merged into the ISO C++ Standard.
Clang 5 and later implement all the features of the C++ 2017 Draft International Standard.
This seems to refer only to core language features. You probably want to check the libc++ and/or libstdc++ conformance status instead.
https://libcxx.llvm.org/cxx1z_status.html
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html
In the above links, P0024 is not marked as implemented.
Quoting from the GCC page on C++14 support
Important: Because the final ISO C++14 standard was only recently published, GCC's support is experimental. No attempt will be made to maintain backward compatibility with implementations of C++14 features that do not reflect the final standard.
I could not find the official GCC definition of experimental. Does it only apply to backward compatibility wrt non-standard features, as the last sentence mentions? Or does it also indicate stability, or lack thereof? An earlier sentence on the same page says
C++14 features are available as part of the "mainline" GCC compiler in the trunk of GCC's Subversion repository and in GCC 4.8 and later.
To me, this suggests stability. Is this the case? In particular, my question is about GCC 4.9, since that is the earliest version with full C++14 support, according to the aforementioned page.
There is no "official GCC definition", only the official English definition.
The passage means that, where GCC previously implemented experimental prototypes of then-upcoming C++14 features before C++14 was published, future versions will not bother to try to maintain backward compatibility with those experiments.
Backward compatibility between two versions is only maintained with respect to features that were in an International Standard at the time that they were included in those versions.
This is because, prior to standard publication, the specification of new C++ features can change rather dramatically. It would be madness to guarantee that early experiments in support for them would be forwards compatible with the final, true feature as eventually published in a standard.
In short: use experimental features at your own risk and do not expect them to work the same way in the next version of GCC.
I am currently on RHEL 5.4 with gcc 4.1 installed, but I want to use unordered_map. As I found out, this is only introduced in C++11 to the standard, and therefore not available. One alternative would be using __gnu_cxx::hash_map, but I would prefer using standards.
On another development host I happend to have RHEL 6.4 and gcc 4.4, which knows unordered_map, but gives the following warning:
../include/c++/4.4.7/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
From the gcc homepage I can't seem to find out which gcc version supports unordered_map.
[edit]
To clarify my question:
I am stuck to several operating systems and their versions by customer requirements, therefore I cannot always update to the latest GCC version and be happy. I need to maintain compatibility of my software across all platforms.
I am therefore searching for the minimum GCC version required to use unordered_map. I am aware of the fact that supplying -std=c++0x to GCC fixes the error above, but I dont know how far the "experimental" warning means I should not be using unordered_map.
Some guys in this thread strongly advise not to use this experimental C++11 implementation
... so what should I do?
You cannot find such information on the GCC page. There is information about library features, but only about current version of GCC. In your GCC 4.4, you can simply use -std=c++0x flag to remove the warning.
If you are scared about experimental and cannot update the compiler - just don't use unordered_map from C++11. You can write your own, use one from tr1, or use the one from boost, no matter.
If you just look at GCC site - there is message there:
Important: GCC's support for C++11 is still experimental. Some
features were implemented based on early proposals, and no attempt
will be made to maintain backward compatibility when they are updated
to match the final C++11 standard.
By the way, all features of the C++11 standard are realized in GCC, it's actually old standard, since now C++14 is already approved, but support is still expiremental.
I have no idea WHY it's still experimental, for example on clang site:
Clang fully implements all published ISO C++ standards including
C++11, as well as the upcoming C++14 standard, and some parts of the
fledgling C++1z standard, and is considered a production-quality C++
compiler.
And only C++1z support is experimental.
You should upgrade to gcc 4.9.2, if you can. Otherwise use gcc 4.4. They'll both need the -std=c++0x option.
I'm interested in learning C++ more thoroughly now that C++11 is apparently ratified. What compiler currently implements the closest thing available to full C++11 support? How close is said compiler to full support? Are there still major features missing or just language lawyer minutiae?
There's a support matrix on the Apache wiki.
I think the one Scott Meyers maintains on his homepage is pretty good:
http://www.aristeia.com/C++0x/C++0xFeatureAvailability.htm
The llvm C++ compiler "clang" has partial C++11 support; you can see its current state at http://clang.llvm.org/cxx_status.html.
There's also GCC C++0x (or C++11) status page : http://gcc.gnu.org/projects/cxx0x.html
IBM's xlC++ compiler has a basic C++11 feature support page.
To anyone reading this now, as of Jan 2013 Clang 3.2 is probably the most complete C++11 compiler, although the latest dev branch of GCC (4.8.x) is going to bring GCC back on par by the looks of it.
http://clang.llvm.org/cxx_status.html
Just look at that support table! Epic stuff. That's only accounting for currently available stable versions as well whereas the GCC table contains some 4.8 entries.
Like I said though, when GCC 4.8 hits stable release, it's going to be tight between the two again:
http://gcc.gnu.org/projects/cxx0x.html