Talk:cpp/compiler support

Sized deallocation is disabled by default on Clang

I think that the "Sized deallocation" (N3778) entry for Clang (and IBM XLC++) should be switched from "yes" to "maybe" as one (still) needs to opt-in with -fsized-deallocation [1][2]. IMO it should be made obvious that users cannot rely on the feature being readily available (as this apparently isn't common knowledge). At the very least the flag should be mentioned like it is currently done for IBM XLC++. --Enlightenment (talk) 01:32, 15 July 2023 (PDT)

C++23 static_assert(false)

If I have noticed it correctly, then P2593 was accepted into C++23. I think this is missing in the list. Would someone be so kind to check? --Bran (talk) 15:54, 10 March 2023 (PST)

Add Circle compiler?

Maybe the Circle compiler [3] should be added to the list? Its author, Sean Baxter, seems to implement new C++ features quite fast for Circle.

DenizThatMenace (talk) 02:28, 10 November 2021 (PST)

Major update to MSVC features

I've updated all of the MSVC features. We'll soon be publishing a similar reference; I'll link to that when it's online.

I updated the numbering to match what we use internally (and what's in _MSC_VER): 1900 for VS 2015, 19.2 for VS 2017. Since the VS/MSVC numbering schemes are weird, I've added a tooltip for every single entry with the familiar name (e.g., VS 2015). In places where we've got update information I've marked it as VS 2015.U where U corresponds to the public update.

Let me know if this is bad. I could also see pulling the asterisks out and just leaving the tooltips as a decent solution. I don't watch this page closely but my email is my cppreference user name @Microsoft.com.

Apardoe (talk) 18:08, 15 March 2017 (PDT)

Link features to wiki pages

I think we should link the items listed in the left-hand column to their documentation on the wiki as well as the standards proposal document. Standardese isn't always the best way to explain a feature --Legalize (talk) 09:01, 22 June 2015 (PDT)

I agree, links are what makes wikis useful. --Cubbi (talk) 12:11, 22 June 2015 (PDT)

OpenWatcom

What about OpenWatcom? --92.76.187.173 07:03, 18 April 2014 (PDT)

At some point we'll probably have to limit the compilers that we include to "the big ones" just for presentation purposes, but it looks like there's still some room. Would you like to figure out what OpenWatcom supports and add a new column? --Nate (talk) 08:39, 18 April 2014 (PDT)

Nate, you can probably drop Digital Mars C++, too. It can't compile a few C++ libraries I work with regularly. The compile errors are *not* related to obscure features. The last release of the compiler appears to be several years ago. Their C++ mailing list has not had a message since 2012. I did not even bother joining the list to ask questions. Noloader (talk) 20:26, 15 March 2017 (PDT)

Falling behind

This is getting outdated fast, check out Visual Studio 14 CTP. Also, Oracle Studio 12.4 is advertised to have C++11 support "all features except for concurrency, Delegating and Inheriting constructor, and user-defined literals"). (and of course my usual gripe is that this table does not talk about the library, which is more than half of the standard). I don't think this is maintainable given that the level of documentation is very different between compilers. Unless someone takes it upon themselves to write a conformance test and subject various compilers to it.. --Cubbi (talk) 13:38, 3 June 2014 (PDT)

What you say is true. I wonder if it would be useful to somehow more prominently indicate how old the information in the table is, with e.g. a "last updated" date or more prominent labeling of the most recent version of each compiler listed (to better communicate "this info was only updated as of gcc-4.9)? --Nate (talk) 21:50, 3 June 2014 (PDT)

Intel support matrix C++11 C++14 as of december, but still newer than this page (in case someone finds a moment to go over them - their rows are close enough to the ones used here). --Cubbi (talk) 16:50, 22 June 2014 (PDT)

Features in VS 2015 preview --Legalize (talk) 09:13, 8 December 2014 (PST)

I take back my reservations about the viability of this page: enough people appear to be interested in keeping their favorite compilers up to date here. It is the other websites that attempted to aggregate compiler support information that are falling behind. --Cubbi (talk) 06:44, 30 April 2015 (PDT)

Needs C++11 Library Support

For instance, regex isn't supported at all until gcc 4.9. This can be surprising when you consider that the core language features are supported. --Legalize (talk) 09:08, 4 August 2014 (PDT)

Readability improvements

I find it hard to keep track of which compiler is in which column at a glance when scrolled down the list. Thus, I'm wondering, is it worth showing the compilers that have hardly any support for C++11 features? If the table was limited to compilers that support even at least five (maybe more!) C++11 features, it would become much simpler. I'm not sure how useful the table entries are if the situation for the compiler is essentially "doesn't even come close to supporting C++11".

I expect GCC, MSVC, and Clang have a vastly greater user base than any of the other compilers, so it might make sense to put those three together in the list at either end.

I'm happy to make these changes, but not about to without getting some input first :) Sdt (talk) 21:32, 8 September 2014 (PDT)

As someone who's been using IBM, Oracle, Intel, and HP compilers, I'd feel unrepresented. Perhaps it would work with two tables: compilers that support all/most of it (clang, gcc, Intel, MS) and only parts of it (others). Of course I am not sure it's worth rearranging all this outdated information in the first place. --Cubbi (talk) 03:38, 9 September 2014 (PDT)

Collapsables?

The new {{collapse}} template (as seen in cpp/experimental/parallelism and cpp/language/history now) is giving me an idea, I think a great way to make this table managable would be to make summary rows for C++11, C++14, Libfund TS, etc, which would say no, partial, or version where full support was achieved. And these summary rows would [Expand] into per-proposal support details which are shown now. Then it won't even be so intimidating to actually add all 11/14/libfund/etc proposals. --Cubbi (talk) 18:48, 10 August 2015 (PDT)

Fujitsu?

The Fujitsu column was added but no support for anything was indicated. Is this really doing anything useful? --Legalize (talk) 13:39, 19 January 2016 (PST)

there is some discussion of this addition over at User_talk:PhilMiller. To quote myself "Fujitsu microprocessors were bought by Spansion in 2013, which merged with Cypress Semiconductor in 2014. Based on Cypress's website, their current compiler for the former Fujitsu microprocessors is Softune C++ V6, which only supports C++98", so I dropped Fujitsu from the table. --Cubbi (talk) 14:04, 19 January 2016 (PST)

Splitting and folding the table

The table is large and will only keep growing. As pointed out on User_talk:PhilMiller, there are fewer library implementations than compiler implementations, so it would make a very real sense to split the table in two: core proposals and library proposals. And then if it could use some sort of fold (like what we use on cpp/language/history to collapse the rows you're not interested in, it would actually become manageable. Comments? --Cubbi (talk) 13:14, 13 July 2016 (PDT)

Feature missing

I do not see Expression SFINAE in the features table, although it is a very important feature, and something still not supported by MSVC (one of the last standing no conformance). Would love to see someone go after which compiler versions picked up support.

MSVC version numbers are confusing

The chart heading lists MSVC, which is Microsoft's C/C++ compiler. The compiler program is cl.exe, and it can be checked with the macro _MSC_VER.

A number of the rows in the chart list 14 for MSVC, which indicates MSVC 14.00. That's the compiler that shipped with Visual Studio 2005. Confer, https://en.wikipedia.org/wiki/Microsoft_Visual_Studio#History.

I believe the intention of "14" is to relay the [unused] Visual Studio version number. "Unused" means we call it "Visual Studio 2015", and not "Visual Studio 14". The compiler version that shipped with VS2015 is MSVC 19.00.

Labeling the heading as the compiler (MSVC), citing other compiler versions (like Clang and GCC), and then using the unused Visual Studio version is very confusing.

Its also worth mentioning that you can download the MSVC compiler *without* Visual Studio. Microsoft calls it "VC++ Build Tools". The download includes Nmake, Cl (compiler), Link (linker) and a few other command line utilities. Confer, http://landinghub.visualstudio.com/visual-cpp-build-tools.

Noloader (talk) 00:01, 15 March 2017 (PDT)

oh yes, the infamous MSVC versioning. Visual studio 2017 aka 15 aka 14.10 aka 19.10. Perhaps using full year number would make it sufficiently unambiguous? --06:01, 15 March 2017 (PDT)

Feature testing macros

It would be nice to see this page:

http://en.cppreference.com/w/User_talk:D41D8CD98F/feature_testing_macros

Moved from its current user page and added as a new section somewhere around here. It is a very useful reference, but right now it's only a user page.

I'm reluctant to mess with others' userspace, both because it's, well, their userspace, and because that's often an indication that the page is a WIP and isn't ready for prime time. If D41D8CD98F wants to, they can do it themselves - perhaps drop a note on their talk page? T. Canens (talk) 15:38, 13 September 2017 (PDT)

I've added a link to cpp/experimental/feature_test to the front page, though if you only care about gcc and libstdc++, https://gcc.gnu.org/projects/cxx-status.html and https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html might be better references, as they are most close to what implementers actually define. Also beware that in clang, some features may be available even if the corresponding macros do not indicate so. E.g. clang 3.9 supports "Differing begin and end types in range-based for", despite __cpp_range_based_for being defined as 200907 and not 201603. --D41D8CD98F (talk) 22:00, 13 September 2017 (PDT)

About designated initializers

Designated initializers of GCC and Clang(?) are C-version, I test with gcc 4.9.6, it's invaild use designated initializers in *.cpp or cpp compiler options, we can *ONLY* use them in C with gcc 4.9.6 and there are also many differences between C nad C++ version

so we could:
A.mark they're C-feature and turn them to red
B.use yellow backgroud if they still mark 'partial'
C.more ideas...

let's talk about that here!

I tested every version available on wandbox. GCC in C++ mode does not support C designated initializers, in any version. Saying that in this table was definitely a lie. The language extension that GCC supports in C++ mode is what they call "trivial designated initializers", a tiny subset of C's designated initializer feature set, and that's exactly what was standardized as part of C++20, with a couple of tweaks (equals sign was made optional, and the order of evaluation was enforced). Clang in C++ mode does in fact support C designated initializers (not a GCC-like subset), but they are a superset of this feature, except for the optional equals sign. It's just a case of the C++ standard doing its job and documenting something the compilers already do. --Cubbi (talk) 05:03, 24 October 2017 (PDT)

how about make 'partial' and 'TS only' turn yellow?

Presumably next major version will have full support, would it be switched to green then? I guess it makes sense. Note we already have a number of cells where different levels of support were present in different compiler versions, see many entries in C++11 part of the table. --Cubbi (talk) 07:29, 24 October 2017 (PDT)

More accurate MSVC version numbers

Currently there are many features for which the MSVC compiler added support for in minor updates (ie. 19.11 and 19.12), but the list only lists the 3 most significant digits of the version (ie. 19.0 and 19.1) and indicates the exact update with the appropriate IDE marketing name hover tip. Would it be acceptable to change the version numbers to include an additional minor version number point, so they can be more easily distinguished?

As a side note, since VS 2017, the IDE itself and the installer refer to the IDE release by the version number (ie. VS 15.4.3, VS 15.5.0) instead of the marketing name (ie. VS 2017.4, VS 2017.5), maybe it'd also make sense to change the hovers to refer to the appropriate IDE release by the exact version number instead of the marketing name, where possible?

CMake 'target_compiler_feature' flag

It might be useful to have an annotation somewhere of the argument to CMake's target_compiler_feature that corresponds to each feature.

Adding a column for Apple Clang

Would anyone be against adding a column for Apple Clang? Tooltips would be used for the matching Xcode version. There are sometimes huge discrepancies between regular and Apple-shipped Clang regarding feature support. I discussed this on Reddit and at least one cppreference wiki editor supported adding such a column.

The version information for Apple Clang and Xcode has been gathered in this gist: https://gist.github.com/yamaya/2924292

Pointing to authoritative references on feature support seems to be impossible in many cases and we would have to rely on anecdotal evidence. The only information in Xcode release notes I've been able to find is support for <any>, <optional> and <variant>. Pre-10 Xcode release notes do not seem to contain anything useful.

Even though the situation with the references is not ideal, there is real demand for a best-effort collection of this information. If no one protests in two weeks, I will create the new column and add the initial references. --Buovjaga (talk) 00:08, 8 February 2019 (PST)

I think it's a good idea - certainly more XCode users use cppreference than Cray users. Probably enough to keep this up to date. --Cubbi (talk) 08:30, 8 February 2019 (PST)

I'm currently porting bits of a project to C++20 and I'm using Xcode 11 on the CI server. I do notice that some features are available with it (for example std::remove_cvref_t) but I've got no plan to go back and check Xcode 10. I guess that mentioning in the page that they're available in 11 might make people think that they aren't available with 10 even though it's merely untested, and thus I better leave the corresponding cells empty? Morwenn (talk) 14:44, 20 August 2019 (PDT)

Add Nvidia Cuda nvcc column

I'm learning that Nvidia's nvcc compiler driver/wrapper for CUDA programs has its own notion of what bits of C++ it can handle. Perhaps we should have a column for it.

Here's a reference table: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#c-cplusplus-language-support PhilMiller (talk) 13:20, 16 May 2019 (PDT)

Added everything as of 2019-05-16. The table lists 9.0, even though 10.1 is released

C++2a "using enum" (p1099) feature not in the list

The C++2a "using enum" (p1099r5 at the time of writing) feature is not present in the compiler support list. http://wg21.link/p1099

AeroStun (talk) 15:37, 23 September 2019 (PDT)

should std::to_chars / from_chars here (especially floating point support) added here

It seems, that just a few (currently MS only ?) compiler support std::to_char / std::from_char, at least when converting from/to a float/double.

Split versions into their own pages

As more C++ versions coming, this page become more huge and hard to edit. Years ago I put DRs in C++ History into different pages to shrink its size. Months ago Someone else splitted C++ versions into different pages. Recently I have managed to build those pages, DRs have been added due to their templates. But compiler support can't because it is an entire page. And I think it's also about time for this page to split to shrink size. Yaossg (talk) 20:06, 27 January 2020 (PST)

Remove dead table columns for C++20

I would like to remove the last 7 column of compilers in the "C++20 core language features" table. E.g. IBM XLC++, Sun/Oracle C++, Embarcadero C++ Builder, Cray, Portland Group (PGI), Nvidia nvcc.

These don't support a single feature from C++20 it seems and just make the table harder to read. From my PoV, it doesn't make sense to mention a product that supports nothing. (Same for the "C++20 library features" and C++14 tables) --JanStecker (talk) 15:34, 27 April 2020 (PDT)

I think we should not remove a column until we find out that the compiler does indeed not support any of the features. If it does, we should obviously update the table; if it doesn't, then the column should be removed, but a note should be placed near the table explicitly stating something along the lines of "as of <date>, <compiler> still doesn't state support for any of the features of this revision of the standard". — Radix (talk) 18:22, 27 April 2020 (PDT)

type_traits (is_trivially_xxx) in gcc

This is only complete since gcc 5.1. ref to: https://gcc.gnu.org/gcc-5/changes.html

While this is marked as 'library completion', the compiler-support required by such features is necessary, so I would call this core language support as well.

This is currently not mentioned on this page. A proper description about this fact should be added to this page so that someone using an old version of gcc (4.8.x or 4.9.x) won't be confused about std::is_trivially_xxx not being recognized.

I am the original author of this section. Resolved now by adding missing drafts and correcting supporting versions. Yumeyao (talk) 22:40, 14 January 2021 (PST)

"FP" mentioned exclusively in "Elementary string conversions" look not obvious. I initially thought it might be "fast parsing" or something like that; it took time to think about "floating point" (I admit I'm slow). It would be nice to mention that in popup comment. 2A00:5F00:102:0:5510:71F0:C657:7547 01:26, 3 February 2021 (PST) Mike Kaganski

✔. --Space Mission (talk) 02:53, 3 February 2021 (PST)

Compiler specific pages

This page lists compiler support but not from a practical perspective. Maybe we should have a page per compiler to list those command line options required to make it actually compile a compliant program, preferably without warnings about anything in the standard library. I'm particularly thinking about MSVC and the infamous __cplusplus "support" and the fact that, out of the box, it will refer to numerous C functions as obsolete, e.g. strtok even though the alternatives are not in std C++.

Obviously we don't want the gory details but for many programmers this is their primary source of information on writing standard C++.

194.74.130.171 01:39, 15 April 2021 (PDT)

Without commenting on whether this would be a good idea or not:

MSVC minimum: /permissive- /W4, optionally /std:c++latest /std:c17 /Zc:__cplusplus /O2

GCC/clang minimum: -pedantic -Wall -Wextra, optionally -std=c++20 -O3 -g

--Ybab321 (talk) 04:51, 15 April 2021 (PDT)

Broken Template Include

The last include of 'cpp/compiler support/11' has been broken and mediawiki warns as followed:

Warning: Template include size is too large. Some templates will not be included.

Is there any approach to solve this problem? Yaossg (talk) 20:30, 23 May 2022 (PDT)

Seems like this is a common problem with MediaWiki & "heavy templates": google search gives this. A solution (if any) might be found here. --Space Mission (talk) 15:11, 19 June 2022 (PDT)

And the current properties of the "compiler support page" are:

NewPP limit report
Preprocessor visited node count: 95131/1000000
Preprocessor generated node count: 60243/1000000
Post‐expand include size: 2093193/2097152 bytes   <-- this counter is approaching the limit :()
Template argument size: 902987/2097152 bytes
Highest expansion depth: 16/40
Expensive parser function count: 0/100

Some tricks to solve this template non-inclusion problem:

• One approach is to increase the $wgMaxArticleSize limit on the server side (i.e. to tune WikiMedia-instance config).
• Or to insert the tables back into the main page instead of inserting them via wiki-templates (but this is inconvenient for editors).
• Or to keep sub-pages with C++ revisions as separate pages (as it is already done) and link them in (C++11 and C++14 pages could be added via links, the most recent revisions might stay incorporated via templates). --Space Mission (talk) 16:18, 19 June 2022 (PDT). Edited: --Space Mission (talk) 06:27, 20 June 2022 (PDT)

Personally I prefer the last option since that's exactly the reason why I originally split these tables into templates.Yaossg (talk) 08:04, 20 June 2022 (PDT)

+1 for the last option --Ybab321 (talk) 10:19, 20 June 2022 (PDT)

✔ Done, I hope.) --Space Mission (talk) 03:06, 22 June 2022 (PDT)

std::expected missing in GCC 12

According to the table <expected> is available in GCC 12. The header can indeed be included, but std::expected does not seem to exist.

It would be nice if someone could double-check this. --Bran (talk) 08:33, 13 July 2022 (PDT)

To make std::expected etc. accessible it's necessary to compile in C++23 mode, i.e. with option -std=c++23, for example g++ -std=c++23 ./example_std_expected.cpp. From cppreference perspective, taking into account that gcc-12 is available as online back-end, it worth to add C++23 mode into online compiler's menu list => that gadget.

Thanks for suggestion! :) --Space Mission (talk) 15:49, 13 July 2022 (PDT)

And now, as you can see, it runs in default (C++23) mode, as expected:)

Run this code

#include <expected>
#include <iostream>
 
std::expected<double, int> test() { return 3.14159; }
 
int main()
{
    if (auto e = test()) std::cout << "Pi ~ " << e.value() << '\n';
}

--Space Mission (talk) 04:48, 14 July 2022 (PDT)

Do we even need to mention Clang experimental features?

It's great that some features available in Clang hence being incomplete. Do they needed to be mentioned?! If feature rtequires you rebuild compiler, find unicorn or fly to Mars - feature IS NOT available for general users. My propose is to stop doing this:

"Prior to libc++ 16, this feature is considered experimental and is disabled by default. Prior to libc++ 15, support can be enabled with -DLIBCXX_ENABLE_INCOMPLETE_FEATURES=ON when building LLVM. In libc++ 15, this feature can be enabled with the -fexperimental-library compiler flag when using libc++ (see https://libcxx.llvm.org/UsingLibcxx.html#enabling-experimental-c-library-features). In libc++ 16, this feature is enabled by default."

I'm personally perfectly happy for that prose to be in the hover text. I would say that the listed version number in that case should be "16" though; prior to 16 being released, I think I would prefer if it said "15 (experimental)"; prior to 15, I think if you need to build the library from scratch, it may as well be listed as "14 (partial)". --Ybab321 (talk) 02:39, 10 October 2022 (PDT)