Talk:Main Page/suggestions/archive

error in description
If the requested substring extends past the end of the string, or if count == npos, the returned substring is [pos, size).

is only correct if pos==0, it is indeed [pos, size-pos)

2A02:8109:8AC0:44F0:8D26:D9BA:67A0:17DA 00:23, 12 February 2019 (PST)


 * The example in that page (which is cpp/string/basic_string/substr, to provide context), demonstrates this sentence: a.substr(a.size-3, 50) returns "hij", which is [pos, size) or [17,20) in that case. --Cubbi (talk) 07:20, 12 February 2019 (PST)

Version switch
With new versions of standard, many pages become bloated with many versions of the same function, differing by very little. In my opinion it results in them being unreadable. This is very generic suggestion, but it would be nice to have mechanism (maybe browser plugin?) allowing to show only state as it used to be at the requested version, without things already removed or added later. Kaznov (talk) 09:19, 14 February 2019 (PST)
 * we have that, you can enable it in Special:Preferences --Cubbi (talk) 11:41, 14 February 2019 (PST)

errors about concept in template_parameters page
hi man ,

I have read the template_parameters in cppreference, and I found there are two kinds of errors in []

1) missing "bool" before "concept" 2) missing ellipsis before T in template void f5;    // OK: T is a type template-parameter

I use the below codes to complies in

and the compile command is g++ -std=c++2a -O2 -Wall -fconcepts -pedantic -pthread main.cpp && ./a.out

then I have no get errors any more , I am not sure the cppreference error or compiler bugs, could you please check it double , thank you very much.

--http://www.lisuwang.com 23:25, 13 February 2019 (PST)


 * gcc -fconcepts is the TS concepts, C++20 has different concepts. You can compile our example using clang here: https://gcc.godbolt.org/z/rVC5N5 --Cubbi (talk)

Requesting permission for adding examples
I wanted to enter an example for cpp/string/basic_string_view/empty but that page is locked (due to vandalism).

I'd like to request permission for entering examples, as I'm going through some pages that do not have examples and could take the opportunity to add some. Here's the precise example I wanted to include for the aforementioned page:

Rnsanchez (talk) 04:20, 18 February 2019 (PST)
 * I've added the example with tiny modifications. See cpp/string/basic_string_view/example empty size. --Fruderica (talk) 05:21, 18 February 2019 (PST)
 * Note that argv[0] can be a null pointer (it is, if and only if argc == 0). And it can point to an empty string (only if argc >= 1), so one of the comments is erroneous. Also, "surround" should be "surrounded". 2001:B01:2404:4:0:0:0:59 06:07, 19 February 2019 (PST)


 * Thanks for including and improving it! --Rnsanchez (talk) 10:58, 18 February 2019 (PST)

Sentence clarity in Template:cpp/error/exception/constructor
With this edit, the edited sentence has become a garden-path sentence and thus difficult to parse, and I think it could be reworded. I suggest "Because throwing exceptions during the copy of a standard library class derived from std::exception is not permitted". 2601:1C0:4700:7AF4:5D48:D85F:C64F:6ED 14:27, 19 February 2019 (PST)
 * Reworded slightly. T. Canens (talk) 20:56, 19 March 2019 (PDT)

"powf", "std::powf" or no "powf": which one is standard?
While trying to compile a C++ program on gcc 7.3.0 (Ubuntu 18.04), the compiler complained that

''In function ‘constexpr size_t representable_values’: ../Template/TSTBalance.hpp:19:15: error: ‘powf’ is not a member of ‘std’ return (std::powf(2, sizeof(T) * CHAR_BIT));''

The workaround, in my case, consisted in removing the "std::" prefix from powf and then it worked. This seems to me in contrast with. Moreover, in this SO answer it is claimed that "powf" is not ISO standard at all. So, am I missing something or is there an incongruence?
 * Answers posted above were correct before C++11, since C++98/03 hadn't referred C99 library yet. According to the current standard, is declared in namespace  when  is included (explicitly mentioned since C++17, implicitly mentioned in C++11/14, see also,  and ). For , gcc libstdc++ is not compliant while clang libc++ is. --Fruderica (talk) 03:49, 19 February 2019 (PST)


 * see also this, more recent, SO answer: https://stackoverflow.com/a/54735351 --Cubbi (talk) 08:10, 19 February 2019 (PST)

Example of "Static storage duration"
Hi,

the output of the example at  is described as "*possible* output". Why? Isn't that output the only possible? Thanks. 2001:B01:2404:4:0:0:0:59 06:02, 19 February 2019 (PST)


 * doesn't seem to be a good reason, I removed "possible" --Cubbi (talk) 08:13, 19 February 2019 (PST)


 * Good, thanks :-) 2001:B01:2404:4:0:0:0:59 06:44, 21 February 2019 (PST)

std::pair::swap
In the description of std::pair::swap, I would have benefited from narrative saying something like:

One might think the intent of this function is to swap the two elements of the argument pair. (This would not even make sense when the types of the elements are not identical.) However, this method swaps the entire content of the argument pair with the entire content of the caller. After the call to swap, the contents of both pairs is changed. 198.151.8.4 06:39, 20 February 2019 (PST) sharplesa
 * This interpretation seems implausible given that this is a non-static member function that takes an additional parameter. T. Canens (talk) 10:10, 23 February 2019 (PST)

header/span -- Synopis typo
https://en.cppreference.com/w/cpp/header/span

Typo: Synopis => Synopsis (the second "s" is currently missing).
 * updated --Cubbi (talk) 14:18, 21 February 2019 (PST)

Possibly missing "since C++11"
https://en.cppreference.com/w/cpp/language/static

In the 'Constant static members' section code example there is a variable 'n' and it gets initialized within the class. I tried to use the line with some ancient compiler (visual c++ 6) and it failed. Could it be, that this kind of initialization was a new feature of c++11? This should be made clear then.

79.235.250.122 02:11, 22 February 2019 (PST)
 * no, that's a C++98 feature. --Cubbi (talk) 06:34, 22 February 2019 (PST)

std::terminate - an exception can be thrown during exception handling
point 4 states: 2) an exception is thrown during exception handling (e.g. from a destructor of some local object, or from a function that had to be called during exception handling)

which should instead read "2) an unhandled exception ..." since exceptions can be thrown during exception handling as long as they are handled before stack unwinding completes.
 * Adjusted. T. Canens (talk) 10:08, 23 February 2019 (PST)

Testing
Hello,

can you add my lib to testing group.

thank you

Regards, Gammasoft71

lib : xtd.unit Category : Testing Description : Modern c++17 unit testing library on Windows, macOS, Linux, iOS and android. GitHub page : https://github.com/gammasoft71/xtd.tunit Home page : https://gammasoft71.wixsite.com/xtd-tunit



Gammasoft71 (talk) 11:38, 24 February 2019 (PST)

thread_local initialization moment is not mandated by the standard
"The storage for the object is allocated when the thread begins ..." is not really true per http://eel.is/c++draft/basic.stc#thread:

So in other words, standard does not mandate when initialization is going to take place (it only says that it will be latest before its first odr-use) but also it does not mandate if it will take place at all.

Output of the following program on both gcc and clang produces the output without  being triggered:

Output:

There is no first-odr use of and compilers are free not to initialize (instantiate) the variable at all. To force them to do so one can add sth like void* ptr = &tls; somewhere in the code.

88.207.93.70 01:52, 25 February 2019 (PST)


 * The line you quoted from cpp/language/storage_duration talks about when allocation takes place (compare to static and especially automatic around it), not about initialization, which is covered in cpp/language/initialization. Added a more obvious link. --Cubbi (talk) 13:02, 26 February 2019 (PST)

New user
I’m considered a new user and can’t add to a Talk page’s discussion (specifically, I’d wanted to show my support for the this proposal, but the warning says that “editing of this page is temporarily disabled for new users”). How do I become trusted enough for Talk page edits? Thanks! — LLarson   (said &amp; done) 10:45, 25 February 2019 (PST)
 * It's based on autoconfirmed, so age + edit count. (IOW, the entire wiki modulo this page is effectively semi'd.) Your account is, of course, more than old enough, so it's just edit count. T. Canens (talk) 06:21, 26 February 2019 (PST)
 * @T. Canens: Thanks for the clarification! — LLarson   (said &amp; done) 09:52, 19 March 2019 (PDT)

More detailed example.
For page https://en.cppreference.com/w/cpp/algorithm/unique

Example

 * The behavior is undefined because your predicate is not reflexive. The page used to have a similar example, until this error was pointed out. --Cubbi (talk) 06:46, 1 March 2019 (PST)

notes of cpp/language/static_cast
Notes on cpp/language/static_cast state the static_cast may be used disambiguate function overloads (which is very good to know/read) but than gave a bad example as seen on cpp/string/byte/toupper which discourages this kind of usage, therefore best would be an more suitable example, but with this example it should be linked to cpp/string/byte/toupper and noted that this use might be bad. Rob42 (talk) 01:29, 4 March 2019 (PST)
 * ✅ I've rewritten the example with std, also emphasized the item addressable function introduced per . --Fruderica (talk) 03:10, 4 March 2019 (PST)

the definition of read-read coherence on memory order
the origin text is:

2) Read-read coherence: if a value computation A of some atomic M (a read) happens-before a value computation B on M, and if the value of A comes from a write X on M, then the value of B is either the value stored by X, or the value stored by a side effect Y on M that appears later than X in the modification order of M.

I think it should be:

2) Read-read coherence: if a value computation A of some atomic M (a read) happens-before a value computation B on M, and if the value of *B* comes from a write X on M, then the value of *A* is either the value stored by X, or the value stored by a side effect Y on M that appears *earlier* than X in the modification order of M.
 * We copied this phrasing straight from the standard. T. Canens (talk) 08:23, 9 March 2019 (PST)

basic_iostream typo
in the "inherited from std::basic_ostream" it says "Unformatted input"

Obviously a copy/paste error from the previous section

Espie (talk)
 * Fixed, thanks! T. Canens (talk) 08:18, 9 March 2019 (PST)

”Smart quotes” in std::map::extract
https://en.cppreference.com/w/cpp/container/map/extract

map m{{1,”mango”}, {2,”papaya”}, {3,”guava”}};

Let's not use ”smart quotes” in source code. (They may exist in other std::map members too, didn't check.)

-- 79.136.64.93 14:51, 19 March 2019 (PDT)
 * Fixed. Thanks for pointing it out. --Fruderica (talk) 20:41, 19 March 2019 (PDT)

Poor example in front_inserter
Example in: cpp/iterator/front inserter is poor because it fills three slots at the front of dequeue with -1, which fails to illustrate the order.

Suggest reusing example from front_insert_iterator which clearly shows the elements are inserted reversed (i.e. each insert is at the front, before the last one inserted).

john skaller 49.181.255.99 21:45, 13 February 2019 (PST)


 * done, thx. --Cubbi (talk) 06:51, 22 March 2019 (PDT)

unnecessary include in example code
The "#include " seems to not be required for the example to compile and run. I suggest to remove the line that includes array.

--2001:A61:4702:2F01:8E70:5AFF:FE94:1034 12:47, 26 February 2019 (PST)
 * This is about std? Fixed. T. Canens (talk) 21:03, 19 March 2019 (PDT)

C++ compiler support: dynamic pointer safety (GC interface)
I have a question. Why edits (page: https://en.cppreference.com/w/cpp/compiler_support, 03:57, 4 December 2018) about availability of GC interface in GCC, Clang and MSVC were reverted?

Can someone provide information which part of GC interface is not supported in mentioned versions of compilers? Here is a godbolt example for gcc 6.1, clang 3.4.1 and MSVC 19.0 that compiles fine and do what it should do according to spec. Dk (talk) 05:20, 6 March 2019 (PST)
 * No compiler today implements any part of basic.stc.dynamic.safety, and it would be dishonest to claim that when libraries replace the content of util.dynamic.safety with no-op dummy calls, they "support" this feature: it is of no use to the program looking to use it. The C++11 GC interface does not exist. --Cubbi (talk) 07:12, 6 March 2019 (PST)
 * No, this is wrong. Please refer to basic.stc.dynamic.safety /4. You can querry pointer safety and get valid truthfull answer as enum class pointer_safety. Implementation can have relaxed pointer safity and still support this feature (that is the whole point of relaxed poiter safity). If you want to show which implementation have strict pointer safety please rename "dynamic pointer safety (GC interface)" to "dynamic pointer safety with strict pointer safety" or something (or add another row). When I look at that table I expect to find out which versions of compilers can safely compile code that contains pointer_safety enum and functions from garbage collector support and produce behavior according to spec. Dk (talk) 08:32, 6 March 2019 (PST)


 * Better yet, if "dynamic pointer safety (GC interface)" was indeed about compiler implementation of strong pointer safety instead of actually providing *interface* in standard library, why were EDG, Intel C++ and Portland Group (PGI) compilers labeled as N/A? My guess is that it is precisely because they do not ship an implementation of C++ standard library. Dk (talk) 12:01, 6 March 2019 (PST)
 * good point about 'n/a', removed. --Cubbi (talk) 13:24, 6 March 2019 (PST)
 * How about all other points in my reply? Oh, don't you feel bad that cpprefence claims that no compiler fully support C++11 despite compilers' C++ language conformance pages (from which this information supposedly is taken) states otherwise? For example please refer to gcc conformance page: Pointer safety is marked as implemented. If you feel strongly that in order to support dynamic pointer safety compiler must provide strict pointer safety - just add (green) row below that mentioned if strict pointer safety is supported (Yes / No). Right now information on compiler support for C++11 features is factually incorrect. Dk (talk) 00:51, 7 March 2019 (PST)
 * You wrote in edit summary that "n2670 includes a core feature (basic.stc.dynamic.safety),so n/a is inappropriate for intel etc" please clarify what "core feature" did you mean? Dk (talk) 01:05, 7 March 2019 (PST)
 * I changed the status to "Yes to all", and created a row for the library support. But I think it might be misleading to describe "relaxed pointer safety" as a feature, since it requires nothing. Shall we just remove the row? --Fruderica (talk) 03:45, 7 March 2019 (PST)
 * GCC support status for this feature is No. "yes to all" is certainly more wrong that it was before. --Cubbi (talk)

adding github.com/simplx under concurrency
Hi there,

I'd like to please add our http://github.com/simplx

"Simplx is a C++ development framework for building cache-friendly distributed and concurrent multicore software."

I'm in charge of our github repo; feel free to contact me at  for any questions.

Cheers,

-- Peter

Kluete (talk) 04:05, 7 March 2019 (PST)
 * That link shows nothing C++-related. T. Canens (talk) 21:05, 19 March 2019 (PDT)

std::includes example impl missing template param
Minor nitpick - the second example implementation for std::includes is missing the Compare template parameter — Preceding unsigned comment added by 70.181.91.140 (talk • contribs)
 * Fixed. T. Canens (talk) 17:56, 20 March 2019 (PDT)

fstream example code does not compile under MSVC
Code example for fstream does not compile under MSVC, see: https://godbolt.org/z/Ro3fvH

Recommend changing line

to

Markyparky56 (talk) 10:32, 20 March 2019 (PDT)
 * That's a MSVC bug. We don't cater to buggy compilers. T. Canens (talk) 17:55, 20 March 2019 (PDT)

Autolinker isn't working for ranges::less et al
It's linking to instead of, see

--Ybab321 (talk) 15:53, 20 March 2019 (PDT)
 * Fixed. T. Canens (talk) 17:55, 20 March 2019 (PDT)

algorithm/is_sorted
I don't have a copy of the actual standard, but according to Nicolai Josuttis in The C++ Standard Library, 2nd edition, section 11.5.5, returns  when the input sequence is empty. This special case should be explicitly addressed in the statement describing the return value. Csgehman (talk) 17:21, 20 March 2019 (PDT)
 * it's not really special (it falls out of the definition), but it is notable - I'll add a note. --Cubbi (talk) 05:46, 21 March 2019 (PDT)

std::map::insert_or_assign page
Add example to https://en.cppreference.com/w/cpp/container/map/insert_or_assign. Copy from http://cpptrivia.blogspot.com/2017/10/c17-insertorassign.html

#include #include #include int main {   std::map myMap; myMap.insert_or_assign("a", "apple"    ); myMap.insert_or_assign("b", "bannana"  ); myMap.insert_or_assign("c", "cherry"   ); myMap.insert_or_assign("c", "clementine"); for (const auto &pair : myMap) {     std::cout << pair.first << " : " << pair.second << "; "; }   std::cout << std::endl; return 0; } // Output: a : apple; b : bannana; c : clementine;

WurmD (talk) 09:43, 22 March 2019 (PDT)


 * Done. Fruderica (talk) 05:53, 23 March 2019 (PDT)

std::set::emplace_hint: hint should be after the newly inserted element
The expression of hint in Complexity session is correct but wrong in Parameters session.

Huangqinjin (talk) 04:38, 22 March 2019 (PDT)


 * the parameters section of cpp/container/set/emplace_hint currently describes hint as "iterator to the position before which the new element will be inserted". Looks the same as in Complexity's ("new element is inserted just before hint") to me, though perhaps could be worded nicer. --Cubbi (talk) 06:55, 22 March 2019 (PDT)

std::any examples: Add example of pointer version in "if" condition
The benefit of the pointer any_cast is that it can be used in the condition of an if statement, like this:

if (int* i = std::any_cast (&a)) { std::cout << "a is int: " << *i << "\n"; }   else if (std::string* s = std::any_cast(&a)) { std::cout << "a is std::string: " << *s << "\n"; }   else { std::cout << "a is another type or unset\n"; }

Technically this page already says enough that the reader could figure this out for themselves, but I think an example showing it would really help. 81.98.223.180 06:40, 22 March 2019 (PDT)
 * added. thx --Cubbi (talk) 06:58, 22 March 2019 (PDT)

works only with different types
Tower120 (talk) 05:58, 17 March 2019 (PDT)tower120

Indicates that this data member need not have an address distinct from all other non-static data members of its class.

Explanation
Applies to the name being declared in the declaration of a non-static data member that's not a bit field.

Indicates that this data member need not have an address distinct from all other non-static data members of its class. This means that if the member has an empty type (e.g. stateless Allocator), the compiler may optimise it to occupy no space, just like if it were an empty base.

Note, that only members of different types may overlap. See standard wording

Example

 * The issue has been already mentioned in cpp/language/object. And I guess that it's not good to copy the whole source code to the talk page. Fruderica (talk) 04:35, 18 March 2019 (PDT)
 * Considering that the compiler need not honor no_unique_address at all, it's not clear to me that this is worth emphasizing. T. Canens (talk) 21:08, 19 March 2019 (PDT)
 * ✅ T. Canens (talk) 11:21, 23 March 2019 (PDT)

New user
I was puzzled by some example code using 23m and looked at the

page. A link to

in the "See Also" section would have been very helpful. 217.158.111.130 06:14, 1 March 2019 (PST)


 * ✅ --D41D8CD98F (talk) 21:40, 12 April 2019 (PDT)

string constructors page
The non-member function to_string could be in the "see also" section.


 * ✅ --D41D8CD98F (talk) 21:40, 12 April 2019 (PDT)

Suggesting code correction
Suggesting code correction: Example code should have "%u" instead of "%ju" inside printf. 188.124.215.85 05:12, 23 March 2019 (PDT)dev2@novak5.mail33.com
 * We only use in one example, and that's correct because we are printing a uintmax_t. T. Canens (talk) 11:10, 23 March 2019 (PDT)

C++20 Draft Changes to [variant.helper]
Regarding: https://en.cppreference.com/mwiki/index.php?title=cpp/utility/variant/variant_alternative

As of the current C++20 draft, [variant.helper] specifies that is ill-formed if  if.

The current page does not reflect this.

Meowingtwurtle (talk) 20:00, 25 March 2019 (PDT)
 * ✅ With mentioned. Fruderica (talk) 03:43, 28 March 2019 (PDT)

Clarification on what a trivially copyable type is.
This passage: a trivially copyable type is any type for which the underlying bytes can be copied to an array of char or unsigned char and into a new object of the same type, and the resulting object would have the same value as the original

Should be instead:

a trivially copyable type is any type for which the underlying bytes can be copied to an array of char or unsigned char and back into a new object of the same type, and the resulting object would have the same value as the original

Why: The passage could be interpreted as saying "a trivially copyable type is a type where an object of type T copied to an array of char and object of type T copied to another object of type T such that the array of chars or the other object of type T have the same value as the original object of type T" instead of the intended interpretation that the object of type T is copied into an array of char and BACK into an object of type T.


 * Modified the wording according to basic.types. Fruderica (talk) 04:36, 28 March 2019 (PDT)

Reg: memcpy_s is not working on any compiler
I tried using memcpy_s with the example mentioned in your page. I was able to compile but when i run the program it is not going inside the __STDC_LIB_EXT1__ macro.
 * no C compiler or library vendor implemented Annex K of the C11 standard. There are two, I think, third-party libaries that implement Annex K only (I used one of them to test the examples). --Cubbi (talk) 06:06, 29 March 2019 (PDT)

memory_order
In https://en.cppreference.com/w/cpp/atomic/memory_order

Re "std::memory_order specifies how regular, non-atomic memory accesses are to be ordered around an atomic operation."

This seems incomplete because the order of other *atomic* memory accesses is also affected. (e.g. in the example shown under the relaxed order description, all operations are atomic). Thanks, Dan (talk) 10:23, 31 March 2019 (PDT)


 * relaxed ordering example is not an example of such, but release-acquire ordering is (as it notes in the first sentence of cpp/atomic/memory_order). I'll try to reword the opening sentence. --Cubbi (talk) 05:51, 2 April 2019 (PDT)

Page about 'restrict' appears to have contradicting examples
I tried to start a discussion on the 'restrict' page itself, but a note about vandalism directed me here, I hope this is the right place...

The page I am talking about is this: https://en.cppreference.com/w/c/language/restrict

There is a section 'Function parameter' that in a code sample has this function in it:. It then says about the function: "in the example above, the compiler can infer that a and b do not alias because b's constness guarantees that it cannot become dependent on a in the body of the function".

Later in the same paragraph, the page says "If the programmer were to write , the compiler would be unable to infer non-aliasing of a and b without examining the body of the function."

That to me looks like the same piece of code the both times, and saying contradicting things about it. Was the later piece of code meant to not have the const in it?


 * yes, thanks for spotting. The last piece of code was indeed meant to not have the const in it. It is Example 7 from C2x's paragraph 6.7.3.1/15. --Cubbi (talk) 13:13, 1 April 2019 (PDT)

cpp/language/ub: stale link
Could someone please change the link to: https://godbolt.org/z/y4vIi1. Thank you! --Kijewski (talk) 22:57, 1 April 2019 (PDT)
 * updated, thanks. --Cubbi (talk) 05:45, 2 April 2019 (PDT)

Broken link
Page: https://en.cppreference.com/w/cpp/keyword "reflexpr" in the table refers to a non-existent page https://en.cppreference.com/w/cpp/keyword/reflexpr The page had a title visible in the page source: "cpp/keyword/reflexpr（页面不存在）" According to Google Translate, 页面不存在 means "Page doesn't exist" in Chinese. 65.61.62.12 16:19, 2 April 2019 (PDT)


 * Works for me: the tooltip is "cpp/keyword/reflexpr (page does not exist)" for me, and that's expected because nobody has created this page yet. --D41D8CD98F (talk) 21:40, 12 April 2019 (PDT)

Edit submission for memset function return value
According to manual - memset returns pointer to string passed as an argument ("its first argument", source: ISO/IEC 9899:1990 (``ISO C90'')). However, the article on memset states that return value is a copy of string, which is wrong.

Thank you for attention! Regards, Ch3rrydrunk


 * the memset page c/string/byte/memset does not state that. It describes the return value as "A copy of ", where is defined as "a pointer to the object". I suppose it could do what cpp/string/byte/memset did and describe the returned value simply as . --Cubbi (talk) 16:39, 4 April 2019 (PDT)

Wrong output in the example of std::ranges::iota_view?
The output of the second line should be instead of 9 values since  takes 10 elements.

Onlynagesha (talk) 19:52, 4 April 2019 (PDT)


 * good catch, thanks, changed cpp/ranges/iota_view to take(9). --Cubbi (talk) 07:01, 5 April 2019 (PDT)

typo in std::shared_ptr::operator[] documentation
https://en.cppreference.com/w/cpp/memory/shared_ptr/operator_at

The return value section states that: "A reference to the idx-th element of the array, i.e., get[i]"

The `get[i]` must actually be `get[idx]`.

There is also an extra space after the word "array" if you would like to fix.

Yashas (talk) 07:20, 5 April 2019 (PDT)
 * thanks, fixed. --Cubbi (talk) 08:26, 5 April 2019 (PDT)

Wrong signature on std::experimental::ranges::count_if
Hi there, the function signature for (4) on the page about std::experimental::ranges::count_if should be

count_if(R&& r, Pred pred, Proj proj = Proj{});

instead of

count_if(I first, S last, Pred pred, Proj proj = Proj{});

(Leaving out return type and template declaration for simplicity here—and since I don’t get how to format it correctly.)
 * Fixed. T. Canens (talk) 06:23, 12 April 2019 (PDT)

const_cast
Need to add documentation that const_cast can be used on a non-const object to make it const. WilliamKF (talk) 11:45, 9 April 2019 (PDT)
 * cpp/language/const_cast already lists everything const_cast can do. --Cubbi (talk) 06:54, 10 April 2019 (PDT)

function template
The function_template page should clarify that using extern forces the compiler to not instantiate a template when you know it will be instantiated in a different compilation unit. This helps to reduce compile time and object file size. WilliamKF (talk) 16:48, 9 April 2019 (PDT)
 * it already says that "extern [...] prevents implicit instantiations: the code that would otherwise cause an implicit instantiation has to use the explicit instantiation definition provided somewhere else in the program." --Cubbi (talk) 06:54, 10 April 2019 (PDT)

C/Function declarations: typo
There's a typo at the end of C>Function Declaration#Explanation:


 * parameters may have incomplete type (except that in a, the parameter types after array-to-pointer and functino-to-pointer adjustment must be complete)

This should be function. Easyaspi314 (talk) 06:40, 11 April 2019 (PDT)


 * ✅ Fixed. Thanks! --D41D8CD98F (talk) 21:40, 12 April 2019 (PDT)

Support for C++17 inline variables (P0386R2) in MSVC only syntactic, not semantic
The page suggests that inline variables are supported by MSVC (from 19.12). However, as of the latest MSVC version (19.15) inline variables are supported only syntactically, but not semantically. The entry should be modified to note this.

MSVC does indeed allow inline variables with the same external name to be defined in different translation units, and they occupy the same address, as required by the C++17 standard. However, the constructor is called in each translation unit where the inline variable is defined, contrary to the standard. This can result in undefined behavior, depending on the constructor.

Example:

#include inline struct Foo { Foo { std::cout << "Constructing a Foo" std::endl; } } Instance;
 * Inline.Hpp

#include "Inline.Hpp" int main { return 0; }
 * Inline.cpp

#include "Inline.Hpp"
 * Inline2.cpp

After compiling and linking inline.cpp and inline2.cpp, the output on running is: Constructing a Foo Constructing a Foo

--84.156.151.130 09:03, 11 April 2019 (PDT)


 * there are hundreds of bugs in all current compilers, it's unrealistic to track them here. FWIW, both stackoverflow and the bug report say it doesn't happen in Release mode --Cubbi (talk) 10:41, 11 April 2019 (PDT)

Result modification for atan2, atan2f
61.222.86.99 18:25, 11 April 2019 (PDT) If no errors occur, the arc tangent of y/x should be in the range [-π, +π], not just (-π, +π]. Example.   std::complex e(-1,-1*0.0);    std::cout<<"atan2f{-1 - j0} = "<<atan2f(e.imag,e.real)<<std::endl;    std::cout<<"atan2{-1 - j0} = "<<atan2f(e.imag,e.real)<<std::endl; Result:    atan2f{-1 - j0} = -3.14159     atan2{-1 - j0} = -3.14159


 * ✅ --D41D8CD98F (talk) 21:40, 12 April 2019 (PDT)

Addition to when std::optional contains no value
In std description, the following describes when the object does not contain a value:

The object does not contain a value in the following conditions:


 * The object is default-initialized.
 * The object is initialized with/assigned from a value of type std or an  object that does not contain a value.

I suggest to add something like:

* The member function reset is called

134.79.228.253 12:34, 12 April 2019 (PDT) Hamlet


 * ✅ --D41D8CD98F (talk) 21:40, 12 April 2019 (PDT)

std::variant - stray character in example "'y = "xyz"s;'
In the example for std::variant, https://en.cppreference.com/w/cpp/utility/variant, the final assignment in the example contains the stray character `'s'`, e.g.

'y = "xyz"s;

Drankinatty (talk) 15:42, 12 April 2019 (PDT)


 * . It's using to create a std::string. --D41D8CD98F (talk) 21:40, 12 April 2019 (PDT)

Update description for Yato library
Hi Please update description for Yato library on the page "A list of open source C++ libraries"

New description: Modern C++(14/17) cross-platform STL-compatible library implementing containers, ranges, iterators, type traits and other tools; actors system; type-safe config interface. (Apache-2.0)


 * ✅ Fruderica (talk) 06:59, 21 April 2019 (PDT)

Suggested addition to list of open source C libraries
Hi, this is a suggestion to add MQTT-C to the list of open source C libraries (https://en.cppreference.com/w/c/links/libs).

My proposed change would be to add the following to the Communications section.

Alternatively, if a non-GitHub url is preferred, https://liambindle.ca/MQTT-C is the official url for the MQTT-C documentation.
 * ✅ Fruderica (talk) 06:42, 21 April 2019 (PDT)

Information about MQTT-C
MQTT-C is an MQTT v3.1.1 client written in C. MQTT is a lightweight publisher-subscriber-based messaging protocol that is commonly used in IoT and networking applications where high-latency and low data-rate links are expected. The purpose of MQTT-C is to provide a portable MQTT client, written in C, for embedded systems and PC's alike. MQTT-C does this by providing a transparent Platform Abstraction Layer (PAL) which makes porting to new platforms easy. MQTT-C is completely thread-safe but can also run perfectly fine on single-threaded systems making MQTT-C well-suited for embedded systems and microcontrollers. Finally, MQTT-C is small; there are only two source files totalling less than 2000 lines.

Liambindle (talk) 20:16, 19 March 2019 (PDT)

A couple of suggestions for the libraries page
I would like to suggest a couple of libraries to add to the dedicated page:


 * Backward for printing nice Python-styled stack traces (much better than Boost, at least on Linux) with colors and source snippets, especially on crashes. I use it and I find it very helpful. License: MIT.


 * Frozen for constexpr perfect-hashing-based frozen sets and maps. Didn't actually use them (I needed something slightly different), but I came across it, they seems to be nice and they might be useful to other programmers. License: Apache 2.0.

Gio (talk) 01:22, 22 March 2019 (PDT)


 * ✅ Fruderica (talk) 06:59, 21 April 2019 (PDT)

Add link on EasyQtSql library to A list of open source C++ libraries
I would like to add link to page  cpp/links/libs (Databases section)

Kramolnic (talk) 02:06, 29 March 2019 (PDT)


 * ✅ Fruderica (talk) 07:00, 21 April 2019 (PDT)

Return types of overloads
The return types of the overloads of the double version (i.e. expint without any prefix) should actually be the same as the respective type of the argument and not default to double. Currently, the page lists the following declarations:

double     expint( double arg ); double     expint( float arg ); double     expint( long double arg );

But ISO/IEC JTC 1/SC 22/WG 21 N3060 states in 8.1(4) on p. 10 et seq. that

"Moreover, each double version shall have sufficient additional overloads to determine which of the above three versions to actually call, by the following ordered set of rules: 1. First, if any argument corresponding to a double parameter in the double version has type long double, the long double version is called. 2. Otherwise, if any argument corresponding to a double parameter in the double version has type double or has an integer type, the double version is called. 3. Otherwise, the float version is called."

From my understanding, expint(1.0f) should call expintf(1.0f) and therefore should return float.

Other "Special mathematical functions" such as std::hermite and std::legendre have the same problem on cppreference.

--Thebrandre (talk) 02:30, 29 March 2019 (PDT)
 * yes, I think you're right, fixing. --Cubbi (talk) 06:11, 29 March 2019 (PDT)


 * This rule was not merged into the standard when P0226R1 (Mathematical Special Functions for C++17, v5) was applied (https://github.com/cplusplus/draft/commit/014a1548ee76b12f252abe1591ffaede570f10d0). Should we report this as an issue in the standard? --D41D8CD98F (talk) 10:33, 29 March 2019 (PDT)


 * at least an editorial, I imagine.. It makes no sense for a long double overload to return double, and at least GCC agrees. The rule that's in cmath.syn/2 applies, but says nothing of return types. --Cubbi (talk) 13:15, 29 March 2019 (PDT)


 * These functions are not overloaded according to the synopsis, which may be an editorial mistake... I guess if the overloads were in the synopsis, return types would be specified. --Fruderica (talk) 04:04, 30 March 2019 (PDT)


 * Actually, the editorial issue was already raised: editorial #1247, although it had a bit of a scope expansion in discussion and spawned a different (though related) LWG issue that it has to wait for. both remain open --Cubbi (talk) 05:44, 1 April 2019 (PDT)

Compiler support: Intel C++ v19.0.1
The C++17 support of the Intel C++ compiler needs an update for release 19.0.1.

See: https://software.intel.com/en-us/articles/c17-features-supported-by-intel-c-compiler

Note: The last updated date above the page is incorrect, v19.0 was released in November 2018. Note2: The version shipped with the latest release of Parallels Studio XE 2019 Update 3, identifies itself as version 19.0.3.203.

--Farwaykorse (talk) 07:24, 4 April 2019 (PDT)


 * ✅ Fruderica (talk) 05:45, 21 April 2019 (PDT)

Visual Studio 2019 released - updated C++ compatibility
https://docs.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements?view=vs-2019

https://devblogs.microsoft.com/cppblog/better-template-support-and-error-detection-in-c-modules-with-msvc-2017-version-15-9/

Sebastian --188.195.159.55 08:41, 4 April 2019 (PDT)


 * ✅ Fruderica (talk) 05:45, 21 April 2019 (PDT)

operator new description
In [] the return value for operator new is described as follows: "non-null pointer to suitably aligned memory of size at least size", however the non-throwing versions (5)-(8) do return a nullptr upon failure. The description is therefore misleading.

Proposal: "non-null pointer to suitably aligned memory of size at least size, or null pointer upon failure in versions (5-8)"


 * Added. It seems that forms like are permitted to be non-throwing. --Fruderica (talk) 06:56, 22 April 2019 (PDT)

Math library for new number system, called posits, to replace IEEE floating point
Would like to request for the Universal library to be added to the maths section.

Universal: a C++ template library for universal number arithmetic Universal Numbers, or unums, are a collection of number systems to replace floating point with more efficient and mathematically correct arithmetic properties.

https://github.com/stillwater-sc/universal

Several studies by the National Labs have demonstrated that posits are providing orders of magnitude more accuracy for computational science and engineering applications.

173.162.153.241 16:09, 10 April 2019 (PDT)


 * ✅ Fruderica (talk) 07:00, 21 April 2019 (PDT)

Example uses normal mutex
The example uses a std::mutex instead of std::recursive_mutex. This is an issue because std::mutex::try_lock has undefined behavior when called by a thread owning the mutex. 149.117.146.29 04:57, 11 April 2019 (PDT)
 * Which example? Please link the page. T. Canens (talk) 22:02, 12 April 2019 (PDT)
 * I guess it's Template:cpp/thread/recursive_mutex/example_try_lock --D41D8CD98F (talk) 22:22, 12 April 2019 (PDT)

Bug tips for initialization of static thread_local member on g++ (ver<=7.1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702

maybe this fatal bug should be mentioned on these pages:

https://en.cppreference.com/w/cpp/language/static https://en.cppreference.com/w/cpp/language/storage_duration
 * In general, we don't track compiler bugs. There are too many of those. T. Canens (talk) 22:02, 12 April 2019 (PDT)

C++ Core Guidelines by Bjarne Stroustrup and Herb Sutter
It should be https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines, not the github repo.--81.25.62.47 09:20, 14 April 2019 (PDT)
 * agree, updated cpp/links --Cubbi (talk) 11:03, 15 April 2019 (PDT)

std::thread::sleep example using std::chrono_literals needs C++14 minimum
Just a note on the std::thread::sleep example https://en.cppreference.com/w/cpp/thread/sleep_for, the use of `using namespace std::chrono_literals;` requires C++14, but that is nowhere indicated on the page. Most other examples on cppreference compile against C++11, unless noted. Drankinatty (talk) 00:03, 17 April 2019 (PDT)


 * Read the history. I agree with Cubbi now. Fruderica (talk) 02:44, 21 April 2019 (PDT)

CharTraits
https://en.cppreference.com/w/cpp/named_req/CharTraits only lists basic_string and basic_string_view as consumers. basic_ios, basic_streambuf and everything inheriting from them are blatant omissions partially mentioned in the member-list.

Also, the last change was nearly half a year ago, there is no evidence of vandalism, so the notice is at least inaccurate:

> Due to recent vandalism, editing of this page is temporarily disabled for new users.If you want to suggest a change, please leave a message on the suggestions page for new users instead (don't be surprised if that page appears vandalized!)

--2.203.235.122 10:38, 20 April 2019 (PDT)


 * Added related class templates. The vandalism has happened many times in this year and is not for some specific pages. See this. Fruderica (talk) 02:52, 21 April 2019 (PDT)

C++ keywords: delete
On cpp/keyword/delete, the link to cpp/memory/new/operator_delete is named "allocation functions". The name should probably be changed to "deallocation functions"… Dot (talk) 05:28, 21 April 2019 (PDT)
 * ✅ Fruderica (talk) 05:49, 21 April 2019 (PDT)

Proposal to add one library to the list of libraries: IXWebSocket
155.94.127.115 21:34, 21 April 2019 (PDT) Hi there,

I'd like to suggest adding a reference to my open-source websocket + http library, IXWebSocket to the communication section.

It can be found at https://github.com/machinezone/IXWebSocket

It can be used to write WebSocket clients and servers, and http clients. It has no dependency, supports SSL and the per message deflate WebSocket extension.

Thanks !
 * ✅ Fruderica (talk) 09:22, 22 April 2019 (PDT)

enum and mandatory semicolon
after an enum declaration, I always thought the semicolon was mandatory. But this documentation says it is not!

ex: enum A { something }; //mandatory ?
 * One can write, as the semicolon is only mandatory for the whole declaration, not for the enumeration specifier. --Fruderica (talk) 01:17, 25 April 2019 (PDT)

Edit for cpp/language/coroutines
In section Promise, "The Promise type is determined by the compiler form the return type", please change "form" to "from". Mirokado (talk) 06:23, 24 April 2019 (PDT)
 * ✅ Fruderica (talk) 01:04, 25 April 2019 (PDT)

std::unordered_map erase/empty mixup
On the main page for unordered_map, under the section "Capacity", empty, size, and max_size are correctly listed. However, up at the top of the page, if I hover my mouse over "std::unordered_map" (in the breadcrumb area, C++->Containers library->std::unordered_map), the "Capacity" section incorrectly starts with "erase" rather than "empty".

12.0.122.94 15:49, 25 April 2019 (PDT)SandSnip3r@gmail.com
 * ✅ Fruderica (talk) 18:44, 25 April 2019 (PDT)

GCC-9.1 has support for C++17 parallel algorithms..
Support requires linking to TBB.

In https://en.cppreference.com/mwiki/index.php?title=cpp/compiler_support&action=edit add a gcc line.

Ed Smith-Rowland 205.167.170.20 11:28, 30 April 2019 (PDT)
 * ✅ --Fruderica (talk) 18:28, 30 April 2019 (PDT)

typo at https://en.cppreference.com/w/cpp/language/template_parameters
" a both a " -> " both a " Eirrgang (talk) 06:01, 2 May 2019 (PDT)
 * ✅ Fruderica (talk) 07:41, 2 May 2019 (PDT)

Link to LLVM implementation of offsetof
RE: https://en.cppreference.com/w/cpp/types/offsetof

The location of offsetof has changed in the latest LLVM sources. Rather than linking to master (which could move), I suggest that the link be updated to a stable release branch which shouldn't change:

https://github.com/llvm-mirror/clang/blob/release_70/lib/Headers/stddef.h#L120

Thanks, Andrew R 129.253.240.81 06:49, 2 May 2019 (PDT)
 * ✅ Fruderica (talk) 07:36, 2 May 2019 (PDT)

User-defined literals example: mytype ( unsigned long long m):m(m){} ‘m’ shadows a member of 'this'
Just a curiosity as to whether the example given in https://en.cppreference.com/w/cpp/language/user_literal improperly uses `m` as a shadow of `this` when compiling on gcc with `-Wshadow`. Specifically the example has:

struct mytype {       mytype ( unsigned long long m):m(m){} unsigned long long m;   };

Which when compiled results in:

user_defined_literals.cpp: In constructor ‘mytype::mytype(long long unsigned int)’: user_defined_literals.cpp:12:35: warning: declaration of ‘m’ shadows a member of 'this' [-Wshadow] mytype ( unsigned long long m):m(m){}

It may be perfectly fine, but worth a question.

Drankinatty (talk) 18:30, 3 May 2019 (PDT)
 * I think removing the constructor might be better since it's useless in the example. --Fruderica (talk) 21:10, 3 May 2019 (PDT)

Defect Reports
✅ --Fruderica (talk) 03:12, 7 May 2019 (PDT)

unclear memory_order_relaxed specification
In https://en.cppreference.com/w/cpp/atomic/memory_order

The summary table says for memory_order_relaxed:

> only this operation's atomicity is guaranteed

However the Relaxed ordering section seems to go further by saying

> ...only guarantee atomicity and modification order consistency.

AFAIK there is no modification order consistency - in the sense that different threads may see different sequences of values for a variable stored into and read from with this memory ordering.

If the above is false, please correct me. I haven't found other references to show that the sequence is consistent for different threads (including in the above quoted summary, which says only atomicity is guaranteed - and should be corrected).

However, if it's true, then I guess what is meant is just that there is no tearing, which I think should be phrased differently since the current wording is too vague, IMHO.

--Danra (talk) 09:56, 7 May 2019 (PDT)


 * modification order consistency is guaranteed for every atomic op, regardless of its associated memory order. It's cpp/atomic/memory_order aka [intro.races]/15-18 --Cubbi (talk) 11:25, 7 May 2019 (PDT)

Need (c++20) for items on std::chrono::time_point page
The items for min and max member functions should indicate they are since c++20. Here is the source for those items:

--Mrolle (talk) 13:09, 8 May 2019 (PDT)


 * They have been in the standard since C++11, see (p590, 20.11.6.4, [time.point.special]). --Fruderica (talk) 17:32, 8 May 2019 (PDT)

Possible implementation
Leek (talk) 11:26, 9 May 2019 (PDT)


 * doesn't work --Cubbi (talk) 12:56, 9 May 2019 (PDT)

Possible implementation
Leek (talk) 11:52, 9 May 2019 (PDT)


 * as above. --Cubbi (talk) 12:56, 9 May 2019 (PDT)

MSVC support for C++20 features
I've audited the C++20 tables (aka C++2a) on the "C++ compiler support" page, comparing them against my records of what we've implemented in MSVC's compiler and Standard Library. (Feel free to email/tweet to confirm that I am actually STL.) I found a number of inaccuracies (e.g. VS 2019 16.1 will identify its compiler as version 19.21, but the table refers to it as 19.20, which is correct for only VS 2019 16.0). Also, I have more up-to-date information, so I know what's been checked in for VS 2019 16.1, 16.2, and (in one case) 16.3.

C++20 Core Language features:

These are currently listed as unimplemented; they should be listed as 19.22* with a tooltip of VS 2019 16.2:


 * P0409R2 "Allow lambda-capture [=, this]"
 * P0428R2 "template-parameter-list for generic lambdas"
 * P0624R2 "Default constructible and assignable stateless lambdas"
 * P0780R2 "Pack expansion in lambda init-capture"
 * P0892R2 "explicit(bool)"
 * P0482R6 "char8_t"

These are currently listed as 19.20* with a tooltip of VS 2019 16.1; they should be listed as 19.21* with a tooltip of VS 2019 16.1:


 * P0329R4 "Designated initializers"
 * P0846R0 "ADL and function templates that are not visible"

These are Defect Reports that aren't listed. If listed, they should be listed as 19.21* with a tooltip of VS 2019 16.1:


 * P0961R1 "Relaxing the structured bindings customization point finding rules"
 * P0969R0 "Allowing structured bindings to accessible members"

These are Defect Reports that aren't listed. If listed, they should be marked as unimplemented for MSVC:


 * P0929R2 "Checking for abstract class types"
 * P0962R1 "Relaxing the range-for loop customization point finding rules"
 * P1286R2 "Contra CWG DR1778"

These aren't listed. They're patch papers, but if listed, they should be listed as 19.22* with a tooltip of VS 2019 16.2:


 * P1120R0 "Consistency improvements for <=> and other comparison operators"
 * P1185R2 "<=> != =="

This is currently listed as unimplemented; it should be listed as 19.14* with a tooltip of VS 2017 15.7:


 * P0702R1 "Initializer list constructors in class template argument deduction"

This is currently listed as unimplemented; it should be listed as 19.0* with a tooltip of VS 2015:


 * P0704R1 "const&-qualified pointers to members"

This is currently listed as unimplemented; it should be listed as 19.10* with a tooltip of VS 2017 15.0:


 * P1330R0 "Changing the active member of a union inside constexpr"

This isn't listed. However, it has observable effects. For example, Clang currently forbids "negative_value << whatever" in constexpr, while MSVC permits this. We haven't yet determined if MSVC supports everything necessary for this feature:


 * P1236R1 "Signed integers are two's complement"

This isn't listed. However, it is a significant feature. It also patches the Concepts feature, but it isn't purely a patch. It's unimplemented for MSVC:


 * P1141R2 "Yet another approach for constrained declarations"

This isn't listed. If listed, it should be listed as 19.22* with a tooltip of VS 2019 16.2. We implemented an off-by-default warning C4855:


 * P0806R2 "Deprecate implicit capture of this via [=]"

C++20 Standard Library features:

These are currently listed as unimplemented; they should be listed as 19.22* with a tooltip of VS 2019 16.2:


 * P0463R1 "std::endian"
 * P0020R6 "Floating point atomic"
 * P0653R2 "Utility to convert a pointer to a raw pointer"
 * P0754R2 " "

These are currently listed as 19.20* with a tooltip of VS 2019 16.1; they should be listed as 19.21* with a tooltip of VS 2019 16.1:


 * P0457R2 "String prefix and suffix checking"
 * P0458R2 "contains member function of associative containers"
 * P0769R2 "Add shift to "

These are currently listed as unimplemented; they should be listed as 19.21* with a tooltip of VS 2019 16.1:


 * P0887R1 "std::type_identity"
 * P0318R1 "std::unwrap_ref_decay and std::unwrap_reference"

This is currently listed as unimplemented; it should be listed as 19.22* with a tooltip of VS 2019 16.2:


 * P0482R6 "Library support for char8_t"

This isn't listed. If listed, it should be listed as 19.21* with a tooltip of VS 2019 16.1:


 * P0646R1 "list/forward_list remove/remove_if/unique Return size_type"

This isn't listed. If listed, it should be listed as 19.22* with a tooltip of VS 2019 16.2:


 * P0771R1 "noexcept For std::function's Move Constructor"

This isn't listed. If listed, it should be listed as 19.23* with a tooltip of VS 2019 16.3:


 * P0487R1 "Fixing operator>>(basic_istream&, CharT*)"

This isn't listed. If listed, it should be listed as 19.14* with a tooltip of VS 2017 15.7:


 * P0972R0 "noexcept For zero, min, max"

These aren't listed. If listed, they should be listed as 19.11* with a tooltip of VS 2017 15.3:


 * P0602R4 "Propagating Copy/Move Triviality In variant/optional"
 * P0858R0 "Constexpr Iterator Requirements"

This isn't listed. If listed, it should be listed as 16.0* with a tooltip of VS 2010:


 * P0809R0 "Comparing Unordered Containers"

These aren't listed. If listed, they should be marked as unimplemented for MSVC:


 * P0339R6 "polymorphic_allocator<>"
 * P0340R3 "SFINAE-Friendly underlying_type"
 * P0357R3 "Supporting Incomplete Types In reference_wrapper"
 * P0439R0 "enum class memory_order"
 * P0475R1 "Guaranteed Copy Elision For Piecewise Construction"
 * P0528R3 "Atomic Compare-And-Exchange With Padding Bits"
 * P0551R3 "Thou Shalt Not Specialize std Function Templates!"
 * P0608R3 "Improving variant's Converting Constructor/Assignment"
 * P0616R0 "Using move In "
 * P0619R4 "Removing C++17-Deprecated Features In C++20"
 * P0655R1 "visit"
 * P0738R2 "istream_iterator Cleanup"
 * P0767R1 "Deprecating is_pod"
 * P0879R0 "constexpr For Swapping Functions"
 * P0912R5 "Library Support For Coroutines"
 * P0919R3 "Heterogeneous Lookup For Unordered Containers"
 * P0920R2 "Precalculated Hash Value Lookup"
 * P0935R0 "Eradicating Unnecessarily Explicit Default Constructors"
 * P0966R1 "string::reserve Should Not Shrink"
 * P1001R2 "execution::unseq"
 * P1006R1 "constexpr For pointer_traits::pointer_to"
 * P1020R1 "Smart Pointer Creation With Default Initialization"
 * P1023R0 "constexpr For std::array Comparisons"
 * P1032R1 "Miscellaneous constexpr"
 * P1164R1 "Making create_directory Intuitive"
 * P1165R1 "Consistently Propagating Stateful Allocators In basic_string's operator+"
 * P1285R0 "Improving Completeness Requirements For Type Traits"

C++17 and earlier tables:

I haven't audited these for correctness, but I noticed two issues:


 * P0024R2 "Standardization of Parallelism TS"

is marked as 19.14* (partial). I would like to request that the "(partial)" annotation be removed, and that this cell should be green. As of that version, we support all of the Standard-mandated signatures for use in production code, with Standard-conforming semantics. The Standard doesn't require actual parallelization of anything at runtime; we have actually parallelized a number of important algorithms, with more that shipped in VS 2019 16.0, and we may ship even more in the future. This should be sufficient to claim conformance.


 * P0067R5 "Elementary string conversions"

is marked as 19.14* (no FP), which is correct, and marked as green for 19.15*, which is incorrect. The correct timeline is:


 * 19.14* / VS 2017 15.7: No FP.
 * 19.15* / VS 2017 15.8: FP from_chars.
 * 19.16* / VS 2017 15.9: FP to_chars overloads for shortest decimal.
 * 19.20* / VS 2019 16.0: FP to_chars overloads for shortest hex and precision hex.
 * 19.22* / VS 2019 16.2: FP to_chars overloads for precision fixed and precision scientific.
 * This is Partial; what remains is the FP to_chars overload for precision general.

I believe that libc++ recently implemented integer charconv (no FP) but you should confirm with them.

STL MSFT (talk) 19:04, 9 May 2019 (PDT)


 * Thank you for the information! Now I have corrected currently listed features. But this page says that P1164 has been implemented in VS 2019 16.0. Is it implemented or not? --Fruderica (talk) 21:25, 9 May 2019 (PDT)