Some troubles with compiler mingw_w64 - c++

Yesterday I started making some project and today I check out that my compiler (mingw_w64) is the newest one which I find in Internet (8.1) but I don't have all functions from C++20. So maybe someone know how to figure out this? If it somehow help my IDE is QT creator.

C++ ISO standards and compilers do not progress at the same pace or with the same priorities. Also, C++ standards are available (drafts) before they are complete or officially published: quite often, compilers partially support the draft specs. The good side of this is that there are tables telling you what feature of a given standard is supported by a given version of GCC. You can find such a table for GCC here.

The current latest release of GCC is GCC 11 and C++20 support has been available since GCC 10.
Another compiler is LLVM/Clang, but I don't believe their C++20 support is on the same level as GCC yet, though I excpect it to catch up soon.
Get the latest MinGW-w64 GCC build from: http://winlibs.com/

Related

Do any compilers currently support C++20?

I purchased a book recently entitled beginning C++20. I was looking to begin learning c++ though I now realize that I can't find a compiler that can run the code in the book as I get an error since the compiler I'm using (xcode) does not support c++ 20. I'm wondering if there are any compilers that I can run on my mac that support c++20.
gcc version 8 and up supports some of C++20; you can try using that.
It should also be noted that Xcode isn't a compiler, but instead an IDE that should be using clang as the actual compiler. Clang also currently has support for some of the C++ 20 features. To use them the -std=c++20 flag will still be needed.
Here can you find the currently implemented feature support of the GCC compiler of the C++20 specification:
GCC Link
But you need to enable it in your console command or add this to your toolchain: "-std=c++20"

C++11 features compatibility with different versions of GCC

Following, my previous question about How to safely deploy an application built with an upgraded compiler, there is still a doubt for me about the C++11 features compatibility. Using devtoolset-2, the application that will be built with gcc 4.8.2 but linked with libstdc++.so.6.0.13 will have full C++11 features supported or only the common set with libstdc++6.0.19 ?
I am not really sure to understand this point actually.
You shouldn't be mixing libstdc++ like that, so it's a moot point. You should redistribute the libstdc++ that comes with devtoolset-2 and link against that specifically. Otherwise the compiler and standard library will be at odds with each other, and even they won't know the answer to your question!
Then, simply look up a list of what C++11 features are supported in GCC 4.8.2.

Which gcc version is needed to use unordered_map from C++11?

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.

C++11 with Xcode on Mac OS X Snow Leopard

I have project that is at times developed on Windows/Visual Studio 2010 and uses some C++11 features and I need to be able to develop/build on Mac OS X. When I tried to build the project with Xcode I got a lot of errors around new C++11 features and checked the gcc version to find it's pretty old (4.2).
It looks like Apple is trying to force developers to pay an unnecessary upgrade to Lion by refusing to allow Xcode 4+ to be downloaded on any other version of Mac OS thus I'm left with Xcode 3.x.
How can I continue to use C++11 on Snow Leopard? Is there a way I can do this and keep Xcode as an IDE?
Update feb.25 2012: There are now a lot of features available for you to work with using the latest clang. Maybe you could target 10.6 if you use language features only. If you need library features, you will need 10.7.
given the present (sept.24.2011) state of the Xcode toolset, it's easiest (IMO) to choose another ide or os if you need c++11 support.
the fork of gcc xcode uses will never support these features. clang is pretty far behind wrt c++11 features (because its c++ implementation is still very new and other compilers have had a few extra years). therefore, the compilers xcode ships with do not presently support enough features for c++11 development, regardless of the version of osx you use.
you can install a newer version of gcc and use another ide fairly easily.
technically, you can also make a plugin for xcode 3 (not officially supported) which invokes another compiler (e.g. a more recent release of gcc). that route has been closed in xc4 (afaik). Update apparently, it's still available in Xc4; see idljarn's comment below.
for many projects, it's easier to just use your mac to boot into linux or windows (or use virtualization).
your final option is intel's compiler, which can be used in xcode and provides a decent amount of c++11 support -- try it with xcode before you buy to see if it fits your needs, plays well with xcode, and supports the c++11 features your team uses.
lastly, i don't think they do this for your upgrade money. they really don't maintain xcode for multiple releases very well - they just expect you to stay with the latest and greatest unless you need backwards compatibility; you just stop upgrading in that case. they invested in and assisted development of clang after gcc's license changed. so yeah... osx has always been very far behind wrt c++11 support because they decided to switch to another (very young) compiler. if you wait for xcode to support c++11, you will have to wait for clang to support it, which can be quite some time.
I just saw this now and I would like to update you on this. LLVM currently shipping with XCode is at version 3 (Source). This current version is very good with supporting C++11. Here is a link to what is supported:
http://clang.llvm.org/cxx_status.html
You can compare this with the current GCC support here:
http://gcc.gnu.org/projects/cxx0x.html
As you can see, Clang is currently not far behind, if it is at all, with features of the new standard being supported. The only thing that I see concerning is the lack of support for concurrency features, but that is the case for most C++11 compilers due to the nature of supporting it.So I hope that this answer is not too late and that you are not deterred. Go get the latest version of Xcode and fire away (If you have not done so already ;) )!

C++11 Compiler: Closest to the standard and how close?

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