View source for Talk:Main Page

{{archives|num=3}}
== Unexpected behaviour in cppref search ==

For some reason cppref search box is producing a browser search rather than the standard cpp type  search. I am using Firefox, and there is no setting there to indicate this behaviour.
[[User:BlueWhale|BlueWhale]] ([[User talk:BlueWhale|talk]]) 05:04, 24 February 2021 (PST)

: Same here. Sends the search to Duck Duck Go for me which shows a bunch of unrelated content.

:: Same. Search for "bitset" gives you results for drills and other tools, along with ads. pls rollback whatever messed up the search.

::: FYI, searching "bitset" in the search bar is yielding me [https://puu.sh/Hs6ar/30b643f785.png this page] as expected in all browsers I have --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 08:02, 24 March 2021 (PDT)

:::: And the worse is, we lost quick jump on search box typing. when I want to viewing the vector doc page, previously I just typing "vector" in search box and click the first suggestion, now I have to navigate to duckduckgo one more step. 

== Hiding previous versions of standard ==

Is it possible to hide everything unrelated to particular standard? It should be, because all the "before C++14, since C++14", "before C++17, since C++17" make pages hard to read. For example, look at [[cpp/utility/tuple/tuple|tuple constructor]]. It would be nice to be able to hide everything unrelated to C++17 <or some other> standard. {{unsigned|Hedede|21:04, 12 December 2017 (PST)‎}}

: Yes, it is possible. You can go to [[Special:Preferences#mw-prefsection-gadgets]] and enable the one labeled "<gadget-StandardRevisions>". That will give you a drop-down menu, and from that you can select your interested version. --[[User:D41D8CD98F|D41D8CD98F]] ([[User talk:D41D8CD98F|talk]]) 00:58, 13 December 2017 (PST)

:: That only works for logged-in users. I suspect most people visiting this wiki are not logged in, or even have an account. (There must be server stats for this but I don't know where they are.)
:: It would be really useful to have that gadget visible to everyone. Is there a technical reason that prevents us from enabling a gadget for anonymous users? If not, is there non-technical reason we shouldn't do this? [[User:Guildd|Guildd]] ([[User talk:Guildd|talk]]) 12:25, 19 January 2018 (PST)
::: The issue is that it isn't production quality. I recently spent a few hours testing it and [[User:T. Canens/standard revision gadget notes|made some notes]] on issues. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 13:15, 19 January 2018 (PST)
:::: I wonder if we could put these issues to https://github.com/p12tic/cppreference-doc/issues because it's so easy to lose them here. --[[User:P12|P12]] 14:52, 7 June 2019 (PDT)

: Please see [[cpp/17]], [[cpp/20]].  --[[User:Costa|Costa]] ([[User talk:Costa|talk]]) 10:17, 15 December 2019 (PST)
== Usefulness of translated sites ==

Does anyone have strong feelings about the usefulness of the non-english subsites?

I've gotten a non-trivial amount of feedback from non-english speakers saying that the autotranslated content on those sites is at best useless (it's not very readable and quickly falls out of sync with the english-language content) and at worst disruptive (it can contaminate search results, making it harder for good results to bubble to the top).

People have been making changes to the non-english subsites, but at a very low rate compared to the english site. I don't like the idea of throwing out the translation work that people have done, but at some point the costs may outweigh the benefits.

Thoughts?  --[[User:Nate|Nate]] ([[User talk:Nate|talk]]) 10:05, 13 July 2016 (PDT)
: I only heard bad things about the non-English cppreference as well. --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 11:33, 13 July 2016 (PDT)

: There has been significant amount of work in at least Russian and Chinese wikis and I think the content there is useful, especially given that we don't let search engines index autotranslated pages. The Chinese seems to be very active [http://zh.cppreference.com/mwiki/index.php?title=Special:%E6%9C%80%E8%BF%91%E6%9B%B4%E6%94%B9&limit=500&days=90 even now], although it's single person effort currently. Having said that the rest of the wikis are indeed not attracting interest and are unlikely to take off. I think we could export the content, backup it and shutdown the wikis. If someone thinks he wants to contribute significant amount of time, I could fire up a wiki with the archived content on a personal server on a personal domain for a month and during that time it would become clear if the contributor was serious or only talking. --[[User:P12|P12]] 03:07, 1 February 2017 (PST)
:: Hmm, do we want to make a decision on this? Shut down everything but en (of course), zh, and ru? I have an [[enwiki:WP:AWB|AWB]] bot set up to transform the piles of language links into {{tl|langlinks}}, but if we are doing this then that should probably wait. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 22:03, 3 July 2017 (PDT)
::: OTOH, if we convert to using the template, then we can globally suppress links to the removed languages in the template instead of cleaning up every page, and resurrecting a language - should we ever need to do that - can also be globally done in the template with a few edits. So maybe we should do the transformation anyways... [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 22:12, 3 July 2017 (PDT)

A few years late to the party.  I've been working to bring the Spanish version up to date, I have a few hours a week, but in case this discussion pops up again, don't shut the sites down.  Eventually the idea is to promote es.cppreference.com in universities in Spain, Mexico. Latin America.
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 16:41, 19 March 2020 (PDT)

== Tracking {{tl|noexcept}} and hidden DR comments ==

We've decided - I think - on merging {{tl|noexcept}} into the applicable function signatures, but there's no easy way to see which pages haven't been processed yet. What do people think of the following:
* Using [[Special:ReplaceText]], replace all current uses of {{tl|noexcept}} with a tracking template - say, {{tl|unreviewed noexcept}} - which looks just like {{tl|noexcept}} but has a hidden tracking category added to it.
* We can then process the pages in the category and remove processed pages from the category, until it eventually becomes empty.
We could probably also do something similar with the <nowiki><!--CWG 1234--></nowiki>-style DR markers, most of which probably should go to {{tl|dr list item}}. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 23:35, 30 March 2017 (PDT)
: I think some (many?) of the hidden DR comments are there to tell the future editors why the text differs from published pre-DR standard. Great idea for the noexcept migration though. --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 06:28, 31 March 2017 (PDT)
:: I think it still makes sense to systematically review all the DR comments, though, to ensure that everything is in the DR list. We can still keep them after the review. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 10:46, 31 March 2017 (PDT)
::: true. I started reviewing all DRs manually when DR list was invented (that's what [[User:Cubbi/Sandbox]] is about), but it fell to the bottom of priority list. --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 10:56, 31 March 2017 (PDT)
:: Also, do we want to keep the "Exceptions" section afterwards for simple cases (where we don't have anything to add beyond some combination of (none) and just {{tl|noexcept}})? I'm not sure I see much point in keeping them. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 10:55, 31 March 2017 (PDT)
::: Moving exceptions to the signature sounds fine, as long as the signatures can be formatted such that they're not too hard to parse. I don't see much point in leaving behind empty "Exceptions" sections afterwards. :) --[[User:Nate|Nate]] ([[User talk:Nate|talk]]) 20:04, 1 April 2017 (PDT)

== Exact match in search results ==

When searching, if there is only one hit the site automatically redirects to that page. (http://en.cppreference.com/mwiki/index.php?search=distance)

When there are multiple results including an exact match, it does not automatically forward, although the exact match is listed on top. (http://en.cppreference.com/mwiki/index.php?search=std%3A%3Alist)

This is particularly annoying since quite a lot of searches have two results, one in std and one in std::pmr for example (try searching for vector).

Would there be an easy way to (locally/using an extra GET argument?) change this behaviour, so that it always opens the first page on exact matches?

Also, I'm often too lazy to type the std:: part, but when searching 'set' for example, I usually just want the std::set.

[[User:Ragnar|Ragnar]] ([[User talk:Ragnar|talk]]) 04:25, 2 May 2017 (PDT)
Ragnar

== Wrong line breaking ==

On page [[c/language/operator_logical]]

See screenshot here: https://ibb.co/jc0DL5

== about book ==

book page & subpages seemed to need to update

it uses old-style code background (need to update)

it shows there is 'dynarray' in C++14 (just remove it)

it shows optional appered in C++14 (C++17 in fact)

it says cout means console output (character output in fact, see [[cpp/io/cout]] for more infomation)

== Can you reword http://en.cppreference.com/w/c/memory/malloc and similar pages... ==

... to avoid such: https://stackoverflow.com/questions/46734808/strictly-speaking-does-the-c-standard-require-that-free-must-be-called-after-ma misunderstandings? (I am assuming that this interpretation of your docs is the correct one: https://stackoverflow.com/a/46735077/4385532 - is this correct? )

== Minor search bug ==

Searching for {{c|nullptr}} yields the [[cpp/types/nullptr_t|{{c|nullptr_t}}]] result in the C section --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 11:14, 25 November 2017 (PST)

== gadget-StandardRevisions tool to be updated ==

<gadget-StandardRevisions> is indeed useful
but the problem is that, for example [[cpp/utility/tuple/tuple|tuple constructor]], although constructor declarations of versions other than selected are properly hidden, the description below is ''not''.
Is it a current existing bug, or just unconsidered? Will it please be fixed or added? That will be more pleasant to readers.

== gadget-StandardRevisions tool to be updated ==

The tool can properly work with the (model) declarations.
But it can't work with the description below.
Was this ever considered?
Fixing this will make it more pleasant to readers.

== P0777R1/decay/remove_cvref ==

P0777R1's changes from {{lc|std::decay}} to {{lc|std:remove_cvref}} are behavioral no-ops, even though they might increase compiler throughput. I think revboxing the changes gives them more prominence than they deserve. Possible options I can think of:
* Keep the revboxen as is, even though they don't alter the behavior in any way.
* Drop them and use {{tt|remove_cvref}} throughout even for pre-C++20 features.
* Drop them and keep using {{tt|decay}} for pre-C++20 features (keep {{tt|remove_cvref}} for new features in C++20 and later).
* Drop them and use {{c|remove_cv_t<remove_reference_t<...>>}} for pre-C++20 features

Thoughts? [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 15:40, 19 December 2017 (PST)

: New revisions of standards are made in order to be used by programmers. For me, I try to keep using the latest. For examples, differing standard is not a big problem (at least, not ''so'' convincing to me). A resolution that meets most of demands is to show expressions in different standards, for example: use '''remove_cvref''' in all examples (including pre-C++20 ones) and comment something like "Pre-C++20 can use '''decay(...)''' (or so) instead" so most of the users can find their interesting stuff. --[[User:LittleFlower|LittleFlower]] ([[User talk:LittleFlower|talk]]) 18:35, 23 December 2017 (PST)

== Should we have {{tl|mark macro var}} or {{tl|mark macro}}? ==

Currently {{ltt|c/error/errno}} and {{ltt|c/error|RSIZE_MAX}} are classified as ''macro variable''. Is it better to describe them by a separated template, e.g. {{tl|mark macro var}} (resulting in {{mark|macro variable}}).

<del>And some macros like {{ltt|c/language/operator alternative|and_eq}} and {{ltt|c/error/static_assert}} expand to keywords and operators, and not (constant) expressions. Is it inappropriate to classify them as {{mark macro const}} ? And should a new template, such as {{tl|mark macro}} (resulting in {{mark|macro}}), be used for them?</del>

(together with other templates, e.g. {{tl|dsc macro var}})

[[User:Fruderica|Fruderica]] ([[User talk:Fruderica|talk]]) 02:11, 23 January 2018 (PST)
:Partially done. But it seems that there are not a consistent definition of "variable" in C, which matters. [[User:Fruderica|Fruderica]] ([[User talk:Fruderica|talk]]) 08:54, 18 May 2018 (PDT)

== Return the 'Operator precedence' to the main page ==

May someone do the subj.? Why have this link was removed, at all?
[[User:Beaux monde|Serge Roussak]] ([[User talk:Beaux monde|talk]]) 22:12, 28 January 2018 (PST)

: Operator precedence is a part of Expressions. Only major titles are placed on Main Page. I don't think that's necessary. --[[User:LittleFlower|LittleFlower]] ([[User talk:LittleFlower|talk]]) 19:57, 3 February 2018 (PST)

== replace semicolon by comma as interval notation ==

[[User:Cubbi|Cubbi]] told me semicolon is used in some part of Europe as interval notation but comma is more popular. Since cppreference is facing all over the world, I suppose comma be better used. It seems semicolon has become a practice and there are really a ''lot''... I don't visit the math functions often and am not familiar with the pages there. I changed a few pages but there seems to be such sea of this that I feel exhausted... Will someone please help me do it?--[[User:LittleFlower|LittleFlower]] ([[User talk:LittleFlower|talk]]) 17:35, 8 February 2018 (PST)

== another minor search bug ==

When searching for "endian", you are directly forwarded to https://en.cppreference.com/w/cpp/locale/codecvt_mode, which contains an enum value with "endian" in its name, but since C++ there is the enum endian: https://en.cppreference.com/w/cpp/types/endian. Search should either list both or go to the endian page. [[User:Gemini67|Gemini67]] ([[User talk:Gemini67|talk]]) 23:34, 29 May 2018 (PDT)


== finding rule of zero/three/five ===

It would be nice to find the above page (https://en.cppreference.com/w/cpp/language/rule_of_three) when searching for "rule of zero" or "rule of five". Currently only "rule of three" leads to a search result.

[[Special:Contributions/217.10.52.10|217.10.52.10]] 01:03, 12 August 2019 (PDT) André

== Adding StandardRevisions and `cppreference.com` link to vector skin ==
I've enabled the `Vector` skin to make the list of languages available in the left bar, because I'm from Spain and sometimes I accidentally enter to the Spanish autotranslated version of the site, usually from google searchs. So it's comfortable to me to just click to the English version to get out of there.

The problem is, each time I search for something and move to any other part of the site besides main page, I have to go back to the manual page manually. However, the built-in styles have a the very useful `cppreference.com` link to come back to main page, that is missing in vector.

Also, I've enabled the StandardRevisions gadget and it only works for the built-in styles as well. Is it possible to add support for going back to the main page and the StandardRevisions gadget to the vector style? [[User:Peregringlk|Peregringlk]] ([[User talk:Peregringlk|talk]]) 02:36, 13 September 2019 (PDT)
: It looks like support for the StandardRevisions switcher has been enabled for Vector, so that's  handled. 👍

: To provide a link back to the main page, the simplest solution would seem to be editing [[MediaWiki:sidebar]] to include <pre>** mainpage|mainpage-description</pre> at the top of the first list section. That's normally part of the default sidebar, but was removed for some reason. Since the sidebar is only shown in Vector, which doesn't show the "cppreference.com" link at the top of the page, restoring it should be unproblematic I would think?

: (The messages [[Mediawiki:mainpage]] and [[Mediawiki:mainpage-description]], which are currently undefined and therefore defaulting to "Main Page" and "Main page", respectively) can also be set to customize the link. Setting [[Mediawiki:mainpage-description]] to "cppreference.com" would cause the sidebar link to match the top-of-page link on the custom skin(s). It is possible to localize system messages, for example the default/current [[Mediawiki:mainpage-description/es]] for the Spanish site is "Página principal". Though if it's going to be set to "cppreference.com" that probably doesn't even need localization.)

: Another alternative (or, really, an additional possibility independent of the first suggestion) would be to create a logo image for the site, which could be shown at the top of the sidebar. Currently the logo (which links back to the main page) is present in the Vector rendering, but it's being suppressed in the site CSS because the logo image is still set to the [https://en.cppreference.com/mwiki/skins/common/images/wiki.png eyeball-searingly hideous default placeholder]. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 08:13, 28 October 2021 (PDT)

== Inconsistent capitalization ==

Hi,

just noticing that the entries "C++ Keywords" and "Transactional Memory" are capitalized inconsistently. Also, should the capitalization of

  "External Links  −  Non-ANSI/ISO Libraries  −  Index  −  std Symbol Index"

(and the corresponding C part) be changed accordingly? [[User:Gennaro Prota|Gennaro Prota]] ([[User talk:Gennaro Prota|talk]]) 11:41, 2 February 2020 (PST)

== Redirecting from es.cppreference.com to en.cppreference.com automagically ==

While on the "Página Principal"in es.cppreference.com and want to get to the English version, when I click on the [English] hyperlink there is an error (no redirection).  I've tried to create a redirection, but cannot because there's a restriction in pages with accents (the á in Página).  Any suggestions?

[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 13:34, 18 March 2020 (PDT)
:The main page is like the one place you can't use {{tl|langlinks}} :( [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 20:22, 20 March 2020 (PDT)
::Thx! [[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 09:31, 21 March 2020 (PDT)

== Proposal for Dark-Mode Theme==
Recently StackOverflow launched a Dark Theme(beta) that has been very well received and well implemented. They are currently taking making final tweaks to any of the pages that still have contrast issues, etc.. However, the dark-mode on SO has been brilliant. Eye-strain is greatly reduce which is one of the main benefits. Would Cppreference consider a similar addition of a dark-mode that would provide a choice between light and dark mode that the user could choose through their settings? [[User:Drankinatty|Drankinatty]] ([[User talk:Drankinatty|talk]]) 02:36, 4 April 2020 (PDT)
: Until then, I highly recommend the [https://chrome.google.com/webstore/detail/deluminate/iebboopaeangfpceklajfohhbpkkfiaa Deluminate] extension, it works great with cppreference, as well as Stack Exchange and more-or-less every other website I browse. Whilst we're at it, I propose adding a widescreen variant too, which I'm currently doing with Stylus with the CSS: {{tt|#content, #cpp-head-first, #cpp-head-second, #footer, .mw-geshi, .de1 { width: auto !important; } }} --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 07:56, 4 April 2020 (PDT)
:: I recently looked for acceptable extensions for Firefox. All required excess privileges. Some, like "DarkView" requeted the ability to clear browsing history and delete cookies -- not what you would expect in a dark reader. Seems implementing a dark-mode by cppreference.com for the mediawiki interface would be the safest option -- even if it takes more time to implement. Four years on, this is still a needed addition. The StackOverflow dark-mode model is a good model to look at for implementation, colors, etc.. [[User:Drankinatty|Drankinatty]] ([[User talk:Drankinatty|talk]]) 21:04, 23 August 2024 (PDT)

== Where are level 2 headings? ==

Pages on this site tend to not have level 2 headings even when there are level 3 headings in them. (Examples: [[cpp/preprocessor]], [[cpp/types]], [[cpp/string/basic_string]], [[cpp/thread/mutex/mutex]], [[c/preprocessor]], [[c/string/byte]].) (Sometimes even level 3 is skipped.) Why is that? It kinda bothers me and, I suppose, is not perfect from the point of view of accessibility ([https://habr.com/ru/company/mailru/blog/532268/ a relevant article] (in Russian)) and understanding of content by web-crawlers. (My guess is that H2 elements are by default styled to be quite big and have a bottom border which would look ugly on pages with a lot of short top-level sections. But surely this can be fixed by using a custom style sheet.) — [[User:Radix|Radix]] ([[User talk:Radix|talk]]) 02:12, 12 April 2020 (PDT)

== How to request changes to protected pages? ==

Does this wiki have an interface for requesting an edit/change to a protected page? (Wikipedia seems to have [https://en.wikipedia.org/wiki/Wikipedia:Edit_requests one].) — [[User:Radix|Radix]] ([[User talk:Radix|talk]]) 15:50, 24 April 2020 (PDT)

== Vector skin is missing the standard revision drop-down list. ==

— [[User:Radix|Radix]] ([[User talk:Radix|talk]]) 19:00, 29 April 2020 (PDT)

== A {{c|[[File]]}}'s image is served non-securely. ==

E.g. {{c|[[File:Imbox notice.png]]}} renders into an image with src="http://upload.cppreference.com/mwiki/images/3/31/Imbox_notice.png", i.e. HTTP, not HTTPS. — [[User:Radix|Radix]] ([[User talk:Radix|talk]]) 17:51, 30 April 2020 (PDT)

==Searching in native language==
If I try to search for a term in Spanish on es.cppreference.com, say, for move constructor, "constructor de movimiento" or "constructores de movimiento", nothing is found (''however'', the English term is found (e.g., "move constructor"), . Are we at the mercy of Google indexing the pages, or can we customize pages for:
@1@ Mark the pages with the proper language
@2@ Generate search strings.

<br>
<br>
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 14:04, 1 May 2020 (PDT)

== Linking to WG21 and C++ draft ==

I think it might be useful to add links to WG21 papers that proposed a specific topic.

Maybe a link to the C++ draft could also be helpful?

What do you think?

If you agree, what format would you use?


Example std::string::starts_with

WG21 paper: https://wg21.link/P0457R2

C++ draft: http://eel.is/c++draft/string.starts.with

Defect report: https://cplusplus.github.io/LWG/issue3040


The papers can (sometimes) be found on the language version page or the compiler support page.

https://en.cppreference.com/w/cpp/20

https://en.cppreference.com/w/cpp/compiler_support

But adding it to the specific topic page makes it easier to trace the history of the topic.


Links to defect reports are already available for some topics.

E.g. https://en.cppreference.com/w/cpp/string/basic_string/find


[[User:WimLeflere|WimLeflere]] ([[User talk:WimLeflere|talk]]) 12:15, 16 June 2020 (PDT)

: not sure detailed record-keeping of WG21's activities is well aligned with the core goal of being a resource to programmers: note how those defect reports are there when they are behavior-changing, as in, the programmer may encounter old behavior. Likewise, compiler_support is about what a programmer may or may not use given their toolset.
:One thing I could see as useful is being able to go from the page about a specific language/library feature to its compiler support status/evolution. but how could that be maintained? compiler_support works as it's a single page many people (including people working on the compilers) visit and care about. --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 13:41, 16 June 2020 (PDT)

==Acronym definition for SOCCC?==
I found this acronym in the example for std::string operator+, but not its definition.<br>
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 09:28, 5 August 2020 (PDT)

: It is short for select_on_container_copy_construction. --[[User:D41D8CD98F|D41D8CD98F]] ([[User talk:D41D8CD98F|talk]]) 10:19, 5 August 2020 (PDT)
:: Thx! Added to Acronyms page [[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 12:29, 5 August 2020 (PDT)

== constexpr specified revboxes ==

I think it's getting increasingly important to address the revboxing of C++20 function declarations that are only different by having {{tt|constexpr}} specified. I dislike how [[cpp/string/basic_string/basic_string|string ctor]] is presented, I like how [[cpp/utility/tuple/tuple|tuple ctor]] is presented, and I propose we switch to the latter as a convention. Anyone care to weigh in on this? --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 10:40, 9 August 2020 (PDT)

: one functional difference is that if you use the language version pulldown, string ctor looks a whole lot neater compared to the tuple ctor. Someone has to make the gadget respect {{mark|constexpr since c++20}} --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 12:20, 9 August 2020 (PDT)


So here's what I think is the current and desirable presentation:

'''Current:'''

{{dcl begin}}
{{dcl rev multi | num=1
| until1=c++17 | dcl1= 
basic_string();
explicit basic_string( const Allocator& alloc );
| until2=c++20 | dcl2=
basic_string() noexcept(noexcept( Allocator() )) :
    basic_string( Allocator() ) {}
explicit basic_string( const Allocator& alloc ) noexcept;
| dcl3=
constexpr basic_string() noexcept(noexcept( Allocator() )) :
    basic_string( Allocator() ) {}
explicit constexpr basic_string( const Allocator& alloc ) noexcept;
}}
{{dcl end}}

'''Desirable:'''

Default (Diff) view:

{{dcl begin}}
{{dcl rev begin | num=1}}
{{dcl | until=c++17 |
basic_string();
explicit basic_string( const Allocator& alloc );
}}
{{dcl | since=c++17 | notes={{mark|constexpr since c++20}} |
constexpr basic_string() noexcept(noexcept( Allocator() )) :
    basic_string( Allocator() ) {}
explicit constexpr basic_string( const Allocator& alloc ) noexcept;
}}
{{dcl rev end}}
{{dcl end}}

<gadget-StandardRevisions> in C++98/03 - C++14:

{{dcl begin}}
{{dcl rev begin | num=1}}
{{dcl |
basic_string();
explicit basic_string( const Allocator& alloc );
}}
{{dcl rev end}}
{{dcl end}}

<gadget-StandardRevisions> in C++17:

{{dcl begin}}
{{dcl rev begin | num=1}}
{{dcl |
basic_string() noexcept(noexcept( Allocator() )) :
    basic_string( Allocator() ) {}
explicit basic_string( const Allocator& alloc ) noexcept;
}}
{{dcl rev end}}
{{dcl end}}

<gadget-StandardRevisions> in C++20:

{{dcl begin}}
{{dcl rev begin | num=1}}
{{dcl |
constexpr basic_string() noexcept(noexcept( Allocator() )) :
    basic_string( Allocator() ) {}
explicit constexpr basic_string( const Allocator& alloc ) noexcept;
}}
{{dcl rev end}}
{{dcl end}}

I think the desirable presentation can be achieved by:

1. add {{c|.t-dcl-constexpr-before { display: none } }} to [[MediaWiki:common.css]]

2. change [[MediaWiki:Gadget-standard_revisions.js]] as indicated in the following patch (These are the minimum changes that "work". I made no attempt to make the additions follow the organization of the original code.):
{{collapse top|title=patch}}
<source lang="diff">
--- old
+++ new
@@ -1575,10 +1575,14 @@
     StandardRevisionPlugin.prototype.prepare = function() {
         if (this.is_prepared) {
             return;
         }
 
+        this.constexpr_before = $('.t-dcl-constexpr-before');
+
+        this.constexpr_before.removeClass('t-dcl-constexpr-before');
+
         // initialize scopes
         this.root_scope = Scope.create_root($('#mw-content-text').first());
         this.child_scopes = [];
 
         var self = this;
@@ -1600,10 +1604,12 @@
                 self.prepare_all_li(scope, num_map);
             }
 
         });
 
+        this.constexpr_before.addClass('t-dcl-constexpr-before');
+
         this.is_prepared = true;
     };
 
     /** Utility function. Takes an jQuery object containing an array of
         elements that may or may not contain revision marker.
@@ -1749,12 +1755,17 @@
         be visible and reveals those that no longer need to be hidden (if any).
     */
     StandardRevisionPlugin.prototype.on_selection_change = function() {
         this.prepare();
         var rev = parseInt(this.select.val());
+
         this.tracker.to_rev(rev);
 
+        if (this.curr_rev !== Rev.DIFF && rev === Rev.DIFF) {
+            this.constexpr_before.css('display', 'none');
+        }
+
         // special treatment for rev boxes
         if (this.curr_rev === Rev.DIFF && rev !== Rev.DIFF) {
             this.for_all_scopes(function() {
                 this.rev_tables.each(function() {
                     $(this).addClass('stdrev-rev-hide');
</source>
{{collapse bottom}}
3. update all pages to use the new {{c|t-dcl-constexpr-before}} class.

(After the first two steps, you can visit [[playground]] to see the new presentation.)

--[[User:D41D8CD98F|D41D8CD98F]] ([[User talk:D41D8CD98F|talk]]) 07:01, 5 June 2021 (PDT)

: I really want to see this integrated, I'm happy to start editing the pages to use the new class if we can get this CSS+script merged --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 05:21, 12 June 2021 (PDT)
: Bump <_<; --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 03:23, 8 July 2021 (PDT)

==BaseCharacteristic vs ''base characteristic''==
I'm seeing two different uses of this term.  When defining the UnaryTypeTrait or BinaryTypeTrait, I see the definition of the ''base characteristic'', but other uses, such as in the {{lc|std::negation}} type trait, the term used is BaseCharacteristic (plain font).  Can someone shed some light regarding the proper usage across the site?  My interest is in translating it to Spanish, and I'm just using the translation of ''base characteristic'' for now.<br>
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 08:59, 12 September 2020 (PDT)
:It was originally spelled "BaseCharacteristic" in the standard before it was editorially changed to "base characteristic", so we ended up with a mix. I'll do a global search/replace. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 09:45, 12 September 2020 (PDT)

==Searching for std::regular yields std::Regular in the results==
Needs to be corrected to std::regular.<br> If you can change it in other languages (e.g., Spanish search list), much appreciated.
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 08:20, 22 September 2020 (PDT)

== Searching for C++20 content. ==

Searching for <tt>coroutine_handle</tt> yields nothing. Shouldn't it find https://en.cppreference.com/w/cpp/coroutine/coroutine_handle ?

: 'search' is really a manually-maintained index, which often falls behind. That's why failed search page has links to Google etc, which index must faster --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 14:40, 16 October 2020 (PDT)

== Several of the special mathematical functions have type inconsistent with description ==
I noticed that several of these functions have an {{tt|IntegralType k}} parameter, but the description for {{tt|k}} reads:

    k - elliptic modulus or eccentricity (a value of a floating-point or integral type)

For example, [[cpp/numeric/special_functions/comp_ellint_1|comp_ellint_1]]

Since the function can be a function template, wouldn't {{tt|Arithmetic k}} be a better fit?<br>
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 17:45, 22 October 2020 (PDT)
: The discussion has continued [[Talk:cpp/numeric/special_functions/comp_ellint_2|here]]. This [[cpp/numeric/special_functions#Notes|Note]] is especially enlightening.

==GCC version for es.cppreference.com tops at 9.2, while it tops at 10.2 for cppreference.com==
I'm trying to run the example (which fails on both the English and Spanish sites) for {{tt|std::format}}, and I noticed that the compiler version is different.  Any clues?

[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 10:02, 15 January 2021 (PST)

: Hi, Javier.
* The {{c|std::format}} family is not implemented yet by '''gcc/clang''' (not sure about '''cl'''). To run the examples locally one can use the original [https://fmt.dev/latest/index.html fmt] library, or better, use [https://godbolt.org gotbolt online compiler] choosing the '''fmt''' library from the list of additional libraries and compile with flag {{tt|1=-std=c++20}}. 
* As to the cppreference's Online compilers, the following local discussion can shed the light on: [https://en.cppreference.com/w/MediaWiki_talk:Gadget-ColiruCompiler online compiler]. Note, that the online-compilers are the same - the latest available on Coliru - gcc-v10.2 (and clang-5.0) now. Cubbi has fixed the version's title by changing the [https://en.cppreference.com/w/MediaWiki:Gadget-coliru_compiler.js script (gadget)] for English version. The same could be done for other languages/sites. For instance, on Spanish es.cppreference.com [https://es.cppreference.com/w/MediaWiki:Gadget-coliru_compiler.js this file] may be updated (s/"9.2"/"10.2", or just plain copy from English version would be enough, but admin rights are necessary).

{{anchor|online_compilers_version}}
{{example|A Bonus: cppreference online compier version checker|code=
#include <iostream>
int main() {
#if __clang__
  std::cout << "\nclang-" << __clang_major__ << '.' << __clang_minor__ << '\n';
#else
  std::cout << "\ngcc-" << __GNUC__ << "." << __GNUC_MINOR__ << '\n';
#endif
  // An alternative:
  system("g++ --version");
  system("clang++ --version");
}
}}
: --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 13:01, 15 January 2021 (PST). Edited --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 08:57, 10 June 2022 (PDT)

== TS section minor clean up - 2021. ==

Now, in 2021, when the work on merging [[cpp/experimental/constraints|Concepts TS]] and [[cpp/experimental/ranges|Ranges TS]] into the Standard C++20 is done, these two links can be eventually removed from the Main Page (to reduce the amount of extra information):<br>
{{rrev multi|
|rev1= <br>. . .<br> <br>
|rev2=
[[cpp/experimental|<h4>'''Technical specifications'''</h4>]]
: [[cpp/experimental/lib_extensions|'''Standard library extensions''']] {{mark since libfund ts}}
: . . .
: [[cpp/experimental/constraints|'''Concepts TS''']] {{mark since concepts ts}} ← ''to be removed (?)''
: [[cpp/experimental/ranges|'''Ranges TS''']] {{mark since ranges ts}} ← ''to be removed (?)''
: [[cpp/language/transactional_memory|'''Transactional Memory''']] {{mark since tm ts}}
}}
These pages are (and will be) available via [[cpp/experimental|Technical specification page]].
<br>
: --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 11:01, 16 January 2021 (PST) 8 )

== Search Now Going To DuckDuckGo ==

When I do a search with the search box in the top-right corner it is now taking me to DuckDuckGo. The DuckDuckGo results I see are based on what I was actually searching for on cppreference but it's a bit jarring to suddenly be taken away from cppreference to a DuckDuckGo search results page. It was really nice the way the search worked before where it would take me right to the results within cppreference. 

Is this behavior I'm seeing the way the search will work going forward or have I just stumbled upon a temporary issue? 

~ ~ ~ ~
: it's a test drive to see how users take to an external search. Built-in search looks at a  manually updated index that is partially outdated and incomplete, and is a common cause of complaints. --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 12:06, 22 February 2021 (PST)

: I was also surprised by this and preferred the old way. I've encountered quite a few indexing issue, but never knew it was due to the index being manual. If I'd known that I'd love to have fixed the issues I encountered. It would be nice if built-in search were offered as an user option if the default were to remain DuckDuckGo. [[User:Tambre|Tambre]] ([[User talk:Tambre|talk]]) 22:32, 22 February 2021 (PST)
: Feedback -- External search sucks [[User:Drankinatty|Drankinatty]] ([[User talk:Drankinatty|talk]]) 14:41, 24 February 2021 (PST)
:If you do keep DuckDuckGo, it'd be nice if you could restore the [[enwiki:m:help:keyboard shortcuts#MediaWiki shortcuts|access key for the search box]]. [[Special:Contributions/77.182.132.128|77.182.132.128]] 07:07, 26 February 2021 (PST)
:Can we <b>PLEASE</b> have the internal search back now? The external search sucks so bad, I don't even want to use it and I find myself not using cppreference.com with the ease or to the extent I did before the change. The external search is a really, really bad idea and each result takes 4-10 lines per-hit. So instead of having a nice concise list of what is available on cppreference.com, you have a sprawling DuckDuckGo page that is a complete mess to find the result you want if it isn't in the first two or three results. I have worked with UI design since 1989 and I cannot fathom a worse move for cppreference.com to make. [[User:Drankinatty|Drankinatty]] ([[User talk:Drankinatty|talk]]) 12:50, 27 February 2021 (PST)
:Also note, there is no way for you to determine how users "take to the new search". Users who just find the site and can't stand the external search are not going to take the time to create an account on this site just to provide feedback for the new search (that's if they have 1/2 a clue how wiki internals and talk pages work to begin with). The complaints against the change will be wildly underrepresented, users will just find another reference site that has a cogent interface. Any "sample" that relies on casual site users going to the additional effort to create an account just to provide feedback is statistically invalid. [[User:Drankinatty|Drankinatty]] ([[User talk:Drankinatty|talk]]) 12:58, 27 February 2021 (PST)
:: I understand the frustrations with the new search, but the manual index was ''far'' from the only problem with the old search. Several of them are [[Cppreference talk:FAQ#Search_on_site|discussed here]]. Including...
::* Search was limited to a fixed number of matches (I think 20?) when there were often far more. Without a way to sort, if your desired match would be somewhere off the end of the list it was simply inaccessible.
::* It was impossible, with the old search, to match any articles with titles that contain characters reserved in HTML / HTTP queries, such as an <code>operator&lt;&lt;</code> of some class, e.g. {{ltf|cpp/string/basic_string/operator_ltltgtgt|basic_string::operator<<,>>}}.<br> (DuckDuckGo does... ''better'', with that. It looks like it ignores the <<, and just matches "operator" — but you can at least see the matches beyond the first page, unlike with the old search. Given the number of matches for "operator" on the site, the one you want is very likely to '''not''' be right up front.)
:: -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 20:37, 4 March 2021 (PST)

== Recent Changes Partially Obscure SearchBox with [View|Edit|History|Actions] ==

Sometime in the past week or two, changes made to this site cause the searchbox to be partially obscured by the [View|Edit|History|Actions] tabs. The searchbox size is now about twice the size it was. This is using Firefox 78.7esr. The only times I've seen this before had to do with Gtk+2 to 3 changes, but I don't see how that applies to a website. I have captured an image of what I see. It is posted at https://paste.opensuse.org/51101549 (link good for 30 days)
[[User:Drankinatty|Drankinatty]] ([[User talk:Drankinatty|talk]]) 14:37, 24 February 2021 (PST)
: It looks like the issue is the <code>box-sizing: border-box</code> styling being applied to various page structural elements. The stanza in question looks like this, in the output CSS (when unminified):
<syntaxhighlight lang="css" style="margin-left:2em;">
  div#cpp-head-first,div#cpp-head-second,div#content,div#footer {
    margin: 0 auto;
    position: relative;
    width: 780px;
    -moz-box-sizing: border-box;
    box-sizing: border-box
  }
</syntaxhighlight>
: I just can't figure out where that's ''coming from''! It's not in [[MediaWiki:Common.css]], and if there's a stylesheet file for the Cppreference2 skin I can't find it. But, disable that <code>box-sizing: border-box</code> rule and everything fits correctly again.
: [https://userstyles.org/styles/199156/cppreference-fix-page-header-element-overlapping Here's a userstyle] I just published to userstyles.org, which can be installed to fix the layout issue. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 04:14, 10 March 2021 (PST)
: Setting "border:inherit" to the search text input and buttons make them fit within the design. No clue why the border is set to 10px, it must be for the rest of the wiki design. -- [[Special:Contributions/70.54.171.187|70.54.171.187]] 10:17, 10 March 2021 (PST)
:: @IP User: Technically that's true, but mostly because <code>border: inherit</code> resets the border width of those elements to 0. At that point the <code>box-sizing: border-box</code> has no effect, because borderless elements are the same size no matter how you measure. Therefore, agreed — that change does also serve as a workaround for the problem.
:: Better, though (IMHO) to remove the ill-advised box-sizing rule, which makes everything fit the layout as-is. That way there's no need to sacrifice the current <code>2px</code> (not 10) borders on the search elements. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 16:14, 10 March 2021 (PST)
:I suspect that the CSS is from [https://github.com/p12tic/cppreference-doc/blob/master/skins/cppreference2/screen.css]. Is only Firefox affected? This looks fine in Chrome. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 17:23, 10 March 2021 (PST)
:: I think you're right about Firefox. I just created a blank page, added a search box, and I get borders of 8px. It's most likely part of the default Firefox CSS on Linux (cannot verify for Windows). It looks decent on Android (DDG browser) although it does go over by a few pixels. I guess there's no reset CSS in use here, so maybe a style should be added to force it? -- [[Special:Contributions/70.54.171.187|70.54.171.187]] 07:29, 11 March 2021 (PST)
All, thank you for your efforts, but the search box is still screwed up on Firefox for Linux. Here is a screenshot from today. https://paste.opensuse.org/75444415 (image good for 30 days). I believe you need to force the border (or margin, or padding) of the box to zero in order for it to work properly on Linux. If I recall correctly, the default gets a border that causes the box to appear 2 times its normal size. Really annoying [[User:Drankinatty|Drankinatty]] ([[User talk:Drankinatty|talk]]) 11:54, 28 October 2021 (PDT)
: I applied the box-sizing rule override from the userstyles.org link by FeRDNYC. Does that work? If not, please provide a specific CSS fragment that I can apply - I don't have a linux box readily available to test this on. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 20:16, 28 October 2021 (PDT)
:: @T. Canens: Looks good to me, in either current Firefox or current Chrome. I can drop my userstyle, yay! Thanks for taking care of that. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 15:02, 29 October 2021 (PDT)

== Need edit help for protected template ==

Hey, could I trouble a user with permission to edit the site templates, to take a look at my [[Template talk:inheritance diagram]] suggestion for eliminating the stupid blue ℹ️-in-a-circle icons on the generated inheritance SVGs? It's been there like 6 months and I suspect nobody with the necessary rights has even spotted it. AdvThanksance! -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 21:42, 4 March 2021 (PST)
:{{done}}. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 17:24, 10 March 2021 (PST)

== Compiler support (11, 14, 17, 20) <-- 23! ==

Yeey, we can now add 23 to this list! https://en.cppreference.com/w/cpp/compiler_support/23

: {{mark_ok}} Done. --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 03:58, 27 April 2021 (PDT)

== Killing off the Ranges TS ==

Nobody implemented it, nobody uses it, nobody will implement it, there's no point in writing docs for it, and the javascript hacks to get auto-linking to work for shorter names cause issues for downstream users. What do people think about zapping all the pages and just leave a brief introduction that points to the C++20 ranges library? [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 16:35, 31 May 2021 (PDT)

: My opinion is like this. Emotionally, it is sad to jettison such a great work. But pragmatically, Ranges-TS` pages have fulfilled their progressive mission to be a medium (and playground) between the Proposal and the final IS, and, in light of the aforementioned circumstances, can go now into well-deserved retirement (RIP).
: Probably, the same cleanup should be (conditionally) applied to some other experimental features/TSs when they were merged into the IS. With all respect to the creators of their appropriate pages!
: The idea is to keep the site clean.
: Someone else? --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 23:28, 31 May 2021 (PDT)

:: I'm a huge fan of deleting no-longer-used content, so you have my full support. I support deleting other TS pages too if they've served their purpose --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 04:17, 1 June 2021 (PDT)

::: Yes. Filesystem TS pages are also questionable as people land on its pages from google. --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 10:51, 1 June 2021 (PDT)
:::: libstdc++ and MSVC are still shipping filesystem TS implementations, which is a distinguishing factor in my mind. Perhaps we can <nowiki>__NOINDEX__</nowiki> those pages instead of just deleting them (might need a [https://www.mediawiki.org/wiki/Manual:$wgExemptFromUserRobotsControl server side change] though)? [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 14:20, 1 June 2021 (PDT)
::::: Yea, libc++ ships the {{tt|experimental::filesystem}} as well: {{c|1=/usr/lib/llvm-12/include/c++/v1/experimental/filesystem}}
::::: So:
::::: * bury the Ranges-TS due to the reasons listed above; (?)
::::: * add {{c|1=__NOINDEX__}} flag to pages that have standardized (merged-into IS) alternatives
::::: --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 15:09, 1 June 2021 (PDT)

== Badly rendered pages in zh-version ==

Some long pages for headers in zh-ver, e.g. [https://zh.cppreference.com/w/cpp/header/type_traits the page for {{tt|<type_traits>}}], are badly rendered (for many years). It seems that such issue does not appear in the versions in other languages.

Could administrators analyze and fix this issue?

-- [[User:Fruderica|Fruderica]] ([[User talk:Fruderica|talk]]) 04:45, 16 July 2021 (PDT)

: What's wrong with the way it's rendered? FYI it looks like this for me https://puu.sh/HWNiU/ba8f5e3b06.png --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 08:34, 16 July 2021 (PDT)

:: I know it's been a while (a ''long'' while...), but I wonder if the complaint is perhaps about the Synopsis section? Which, in '''any''' version of the site (including English) is a little dense and impenetrable compared to most of the other cppreference content.
:: In addition, for some reason the lines are re-wrapped when rendering into Chinese, so that for example this section of the English version:
<blockquote><pre>
  // composite type categories:
  template <class T>
  inline constexpr bool is_reference_v = is_reference<T>::value;
  template <class T>
  inline constexpr bool is_arithmetic_v = is_arithmetic<T>::value;
  template <class T>
  inline constexpr bool is_fundamental_v = is_fundamental<T>::value;
  template <class T>
  inline constexpr bool is_object_v = is_object<T>::value;
  template <class T>
  inline constexpr bool is_scalar_v = is_scalar<T>::value;
  template <class T>
  inline constexpr bool is_compound_v = is_compound<T>::value;
  template <class T>
  inline constexpr bool is_member_pointer_v = is_member_pointer<T>::value;
</pre></blockquote>
:: (already not the ''most'' readable) instead becomes '''this''', at zh.cppreference.com:
<blockquote><pre>
  // 复合类型分类
  template <class T> inline constexpr bool is_reference_v
  = is_reference<T>::value;
  template <class T> inline constexpr bool is_arithmetic_v
  = is_arithmetic<T>::value;
  template <class T> inline constexpr bool is_fundamental_v
  = is_fundamental<T>::value;
  template <class T> inline constexpr bool is_object_v
  = is_object<T>::value;
  template <class T> inline constexpr bool is_scalar_v
  = is_scalar<T>::value;
  template <class T> inline constexpr bool is_compound_v
  = is_compound<T>::value;
  template <class T> inline constexpr bool is_member_pointer_v
  = is_member_pointer<T>::value;
</pre></blockquote>
:: Like I said, it's not super-readable even in the English verson, but the Chinese does seem far worse. -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 07:43, 28 October 2021 (PDT)

== Example for shared_lock::lock is broken in gcc 11.1 for C++20 ==
The example at https://en.cppreference.com/w/cpp/thread/shared_lock/lock is toast with the default compiler. It has a dependency on lock_guard (C++17), so if I run it with gcc 11.1 for C++17 it runs just fine.  Can be checked on this link, too: https://coliru.stacked-crooked.com/view?id=178212638b6c1439 [[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 15:24, 17 August 2021 (PDT)
: Hi, ticotico!
: {{mark ok}} Fixed: {{tt|read()}}/{{tt|write()}} trickled down from somewhere, a la [https://pubs.opengroup.org/onlinepubs/009696899/functions/read.html {{tt|read()}}]. .) --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 17:16, 17 August 2021 (PDT)

== C95 and C99 are dead links ==

Not sure if intentional

: You are right. But, this means - Work In Progress.) --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 19:47, 18 August 2021 (PDT)

==In es.cppreference.com, usage of lc template with a header_name does not work, but in the English version it does==
The {{tt|lc}} template is supposed to return the language and then from there build the link to the page.  For example, if I'm in the header page for {{tt|std::latch}}, I can see the link to the class (in blue) in the Engish version, but not in the Spanish version.<br>
Similarly, if I'm in the main page for the thread support library, the references to the header files are not displayed as a hyperlink in the Spanish version, while in the English they are. Could anybody shed some light as to why that is?<br>
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 08:08, 19 August 2021 (PDT)
: {{mark ok}} Fixed: One of the templates was out of date.  [[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 07:46, 21 August 2021 (PDT)

==In es.cppreference.com, Search box is in English and provides results from English search==
The ask is if it can read "Buscar" and point to the search list in Spanish.  It may require an update to the search list--that's been provided before :-)<br>
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 10:20, 26 October 2021 (PDT)

== Install MediaWiki Extension:TemplateSandbox? ==

The MediaWiki standard [https://www.mediawiki.org/wiki/Extension:TemplateSandbox Extension:TemplateSandbox] is handy not so much for the ''sandbox'' ability itself, but for a related feature it brings with it: The ability to preview the results of a template edit ''in situ'' on any page requested, prior to saving the edit and making it live.

The extension adds a field to the editor view (when editing in a namespace configured in <code>$wgTemplateSandboxEditNamespaces</code>), offering to "Preview page with this template". There you can type any page title (presumably one which transcludes the template being edited), and it'll present a rendered view of the page as if your changes had been made live, but '''without''' them actually being made live yet.

Especially on sites where templates are heavily-used, deeply nested, intricately designed, or sparsely documented — and cppreference hits the quadfecta(?) by meeting '''all four''' of those criteria — it beats the more traditional "Edit, Save, Panic, Adjust, Save, Revert" loop that even experienced template coders often find themselves falling into, when attempting to make changes to live templates. As such, it also helps less-experienced editors make changes more confidently, and lowers the barrier to entry for new contributors to get involved in maintaining the site's frontend infrastructure.

Any possibility this highly-useful extension could find its was into the local MediaWiki install? Thx! -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 21:02, 28 October 2021 (PDT)

: This seems like a reasonable request, but it looks like TemplateSandbox requires MW 1.33+ -- once we find time to upgrade the system, I think we can install that template. --[[User:Nate|Nate]] ([[User talk:Nate|talk]]) 06:28, 29 October 2021 (PDT)

:: @Nate: The current version [https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/TemplateSandbox/+/3f2ae2d9006a538935e942c122cdbd71d0934713 actually requires 1.35+], the Extension page is out of date. But as it's a standard extension and developed in their Gerrit instance, it's still possible to download the version that corresponds to any given MW release. [https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/TemplateSandbox/+archive/refs/heads/REL1_21.tar.gz This is the zipfile-download link] for the revision [https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/TemplateSandbox/+/refs/heads/REL1_21 tagged <code>REL1_21</code>], the one that would've originally been released alongside MW 1.21.

:: Upgrading from 1.21 is going to be '''''painful''''', I don't envy you having to make that leap. Upgrading across the 1.2x-1.3x "divide" is known to be a nightmare — just ask Wikia. They basically had to re-implement every piece of their customization last year, to drag FANDOM.com kicking and screaming from a heavily, '''heavily''' customized 1.19.24 to their new 1.33.3-based "Unified Content Platform".

:: I can certainly understand why it's been put off for so long! Though of course, it's only going to get worse the farther behind cppreference falls. (I don't imagine I'm saying anything you don't all already know, of course. Like I said, just... commiserating, really. "Have fun with that!") -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 14:13, 29 October 2021 (PDT)

::: P.S> (I've updated the extension page to list the correct version requirements.) -- [[User:FeRDNYC|FeRDNYC]] ([[User talk:FeRDNYC|talk]]) 14:35, 29 October 2021 (PDT)

==[REDIVIVUS] In es.cppreference.com, Search box is in English and provides results from English search==
The ask is if it can read "Buscar" and point to the search list in Spanish.  It may require an update to the search list--that's been provided before :-)<br>[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 11:58, 1 November 2021 (PDT)

== Discussion on the inconsistency of the arrangement of some related pages ==

The descriptions of singleton object are treated differently.

type and its singleton object described in the same page:
* [[cpp/utility/in_place]] (the page is named after one of their singleton objects)
* [[cpp/memory/new/destroying_delete_t]] (the page is named after its class)
type and its singleton object described in separate pages:
* [[cpp/utility/piecewise_construct_t]] and [[cpp/utility/piecewise_construct]]
* [[cpp/memory/allocator_arg_t]] and [[cpp/memory/allocator_arg]]
* [[cpp/memory/new/nothrow_t]] and [[cpp/memory/new/nothrow]]

For example, in page [[cpp/memory/new]], {{c|nothrow_t}} and {{c|nothrow}} are classified as a class and an object, however, {{c|destroying_delete_t}} and {{c|destroying_delete}} share the same page, as well as the same link, classified as a class.


Similar situations also occurred in function and its corresponding constants/helper classes, but with even worse cases, such as:
* function and its corresponding constants/helper classes described in the same page or separate pages
* a group of functions with similar goals or a common goal described in the same page or separate pages
* functions (of few relation) described alone, with their corresponding constants collected together in a general summary page

Not to mention their links in summary pages and code blocks. It is tough to conclude due to its complexity so we'd better reach a consensus before further modifications.
[[User:Yaossg|Yaossg]] ([[User talk:Yaossg|talk]]) 01:56, 18 April 2022 (PDT)

: I think a justifiable direction would be to merge [[cpp/memory/new/nothrow_t]] into [[cpp/memory/new/nothrow]]: from programmer's point of view, {{tt|nothrow}} is what they see and write in C++ code, and {{tt|nothrow_t}} is perhaps useful to understand an error message or when exploring a standard library headers. Similar to how {{c|std::to_chars_result}} has little use outside the context of [[cpp/utility/to_chars]]. --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 05:52, 18 April 2022 (PDT)

:: Agree. I propose as followed:  [[User:Yaossg|Yaossg]] ([[User talk:Yaossg|talk]]) 23:46, 21 April 2022 (PDT)
* [[cpp/utility/in_place]] remain unchanged
* [[cpp/memory/new/destroying_delete_t]] be renamed to [[cpp/memory/new/destroying_delete]]
* [[cpp/utility/piecewise_construct_t]] be merged into [[cpp/utility/piecewise_construct]]
* [[cpp/memory/allocator_arg_t]] be merged into [[cpp/memory/allocator_arg]]
* [[cpp/memory/new/nothrow_t]] be merged into [[cpp/memory/new/nothrow]]
* Helpers and similar functions maintain the status quo, for further discussion.


== What does the "Member types" section mean on a page? ==

What does the "Member types" section mean on a page? For example on the page 
https://en.cppreference.com/w/cpp/chrono/time_point. At first I thought this simply meant the args to the <> template parameters but there appears to be more types listed there. Perhaps this is a dumb question but I haven't seen an explanation anywhere.
[[User:Jnstaursky|Jnstaursky]] ([[User talk:Jnstaursky|talk]]) 05:56, 7 November 2021 (PST)

: as [[cpp/language/class]] very succinctly illustrates, types can be defined inside a class body. Best known example is probably std::vector<int>::iterator; where "iterator" is such a type. --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 07:18, 7 November 2021 (PST)

== Heading anchor gadget ==

Any chance to get this gadget added? https://www.mediawiki.org/wiki/Special:Gadgets#gadget-vector-headanchor
Headings are already linkable, you just have to guess the heading id or inspect the element or some such, would be nice to simply click the header for URL sharing convenience --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 05:14, 4 January 2022 (PST)

===Localized compiler messages in examples===
Is there a way to pass locale information to the compiler from the examples? GCC supports it.

===Any chance the Searcher named requirement can be added?===
The C++17 searchers make mention of it, but it's nowhere to be found.<br>
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 07:31, 31 March 2022 (PDT)
: Doesn't seem like searchers actually have any requirements [https://timsong-cpp.github.io/cppwp/n4659/alg.search#9] --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 09:50, 31 March 2022 (PDT)
:: it could be informally described from that paragraph (callable with two ForwardIterators etc), returning something on which you can .first to get one back etc --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 13:57, 31 March 2022 (PDT)

== C++ SSE and SSE2 compiler settings, and their Floating Point effects. ==

I have been running C++ floating point tests using the Twilight Dragon Media C++ compiler for 64 bit Windows 10.

[https://jmeubank.github.io/tdm-gcc/]

C++ starts by using IEEE 754 equation for floats and doubles, decimal and hexadecimal values, floating point arithmetic, if I have things right. See this at:

[https://introcs.cs.princeton.edu/java/91float/]

I have learned that when you compile in

A)
'''float a = 0.1F;'''

what you get is stored is

'''0.100000001490116119384765625'''

whereas when you compile in

B)
'''double b = 0.1D;'''

what you get stored is

'''0.1000000000000000055511151231257827021181583404541015625'''

Most of your floating point operators are these:
'''
+, -, *, /, %, ++n, --n, n++, n--, +=, -=, *=, /=, %='''

Is there a GNU C++ switch that will turn off all of these floating point overflow and underflow values, both for assignment of the floating point data and arithmetic operator calculation for separate floating point data, too? How can this be acheived without adjusting the floating point source code at all?

: Think you're looking for Stack Overflow, mate --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 02:27, 31 May 2022 (PDT)

:: The OP posted it on SO [https://stackoverflow.com/questions/72432681 as a question], instead of looking at existing answers, and self-deleted since then to [https://stackoverflow.com/questions/72445688 re-ask], but one of the helful comments on the original question was a link to https://randomascii.wordpress.com/2012/03/21/intermediate-floating-point-precision/ - worth a read --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 12:39, 31 May 2022 (PDT)

== Feature proposal: auto header link ==

It is very convenient that identifiers in the code blocks are auto detected and link to their corresponding function/class/.. pages. I've been thinking if it is feasible that header inclusions in the code could also be detected and link to their corresponding header pages?

For example, following code in cpp pages: (I attempted to use <nowiki>{{</nowiki>lc}} but got broken result, so I used <nowiki>{{</nowiki>c}} instead)

{{c|#include <string>}}

code "&lt;string>" will become a link to [[cpp/header/string]]

--[[User:Yaossg|Yaossg]] ([[User talk:Yaossg|talk]]) 02:39, 28 August 2022 (PDT)

: The auto-generated links are recorded here: [[MediaWiki:Autolinker-definition-cpp]] (which is generated from [https://github.com/p12tic/cppreference-doc/blob/master/index2autolinker.py here]). But this page has not been updated from Feb. 2021, and only Administrators can edit it. --[[User:Guyutongxue|Guyutongxue]] ([[User talk:Guyutongxue|talk]]) 05:41, 28 August 2022 (PDT)

: @Yaossg: I like your idea about auto-linking of headers in Examples (but not sure that it is possible to implement this at present level of technologies in use.)) BTW, there are two files that keep data for auto-linking:
:* for links in pages with tags like {{tl|lc}} it is indeed [[MediaWiki:Autolinker-definition-cpp]],
:* for auto-linking inside Examples, synopses, source code (i.e. with tags like {{tl|example}}, {{tl|source}} etc), there is another list: [[MediaWiki:Geshi-keyword-list-cpp]].
: I'm planning to participate in collecting most of new C++17/20/23 identifiers, when most of C++23 pages will be written (or earlier), and settling them in these two lists (as I once did before).

{{example
|[[cpp/header/iostream|{{c|#include <iostream>}}]]
|code=
#include <iostream>
int main() { std::cout << "test\n"; }
}}
: --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 07:14, 28 August 2022 (PDT)

== Mistakes in set ==

Just found that [[cpp/container/set]] has the following mistakes:
* It mentions <code>key_type</code>, while [https://eel.is/c++draft/container.requirements#container.node.overview-4 the standard says] "using key_type = see below; // not present for set containers"
* It specifies "iterator - Constant LegacyBidirectionalIterator to value_type" and "const_iterator - LegacyBidirectionalIterator to const value_type" while [https://eel.is/c++draft/container.requirements#associative.reqmts.general-6 the standard says] "both iterator and const_iterator are constant iterators" so the description should be identical between iterator and const_iterator (the latter is the accurate one)
I write here because I'm not totally sure how to fix the relevant templates and anyway wanted this to be reviewed in case I misread it

[[User:Yehezkelshb|Yehezkelshb]] ([[User talk:Yehezkelshb|talk]]) 12:10, 8 December 2022 (PST)
: The standard citation you linked in your first point is regarding {{ltt|cpp/container/node_handle}}, which correctly specifies "map containers only" for {{tt|key_type}}. I agree with your second point, and on that note, though the standard says {{tt|set}}'s {{tt|iterator}} and {{tt|const_iterator}} are both "constant iterators" (which means they don't model {{named req|OutputIterator}}), but I would prefer if we wrote "iterator to {{tt|const value_type}}", I don't ''think'' that's inaccurate. --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 15:11, 8 December 2022 (PST)

== Is it possible to donate? ==

I noticed in the FAQ it mentions that hosting costs are offset by ads, donations, and merchandise. I would prefer not to buy merchandise (God knows I have enough already), and I am happy to disable my adblock on the site, but I would like to donate given how much I use the site. Is this possible? [[User:Will eccles|Will eccles]] ([[User talk:Will eccles|talk]]) 15:02, 17 March 2023 (PDT)

: There used to be an option accepting money directly on [https://www.cppreference.com/support/ the support page], but now it's gone... I don't know. Maybe you can ask them through [https://en.cppreference.com/w/Cppreference:FAQ#How_can_I_contact_you.3F their email]. [[User:Studyingegret|Studyingegret]] ([[User talk:Studyingegret|talk]]) 03:54, 22 March 2023 (PDT)

== Mobile site version ==

Is it possible to create a mobile version of this site?
At the moment everything is too small if viewed from a phone. Checking "Desktop site" checkbox and back, in the Chrome mobile, has no effect.
Thanks. [[Special:Contributions/172.70.250.188|172.70.250.188]] 21:50, 8 April 2023 (PDT)

== Proposal: add [[User:D41D8CD98F/append-support-info.js]] for all users ==

[[User:D41D8CD98F/append-support-info.js]] is a script written by me. This script adds a section to the bottom of a page, which shows implementation support information relevant to this page.

Sample screenshots:

* [[cpp/language/delete]]: https://i.imgur.com/UdMLuUg.png
* [[cpp/language/data_members]]: https://i.imgur.com/m1pjJWG.png
* [[cpp/coroutine/generator/~generator]]: https://i.imgur.com/DknpcRD.png
* [[cpp/numeric/special_functions/ellint_3]]: https://i.imgur.com/33q4Guh.png

I believe that this script is useful for all readers, and thus should be enabled for everyone. AFAIK the simplest way to achieve this is adding <span class=t-c><source lang=javascript enclose=none>importScript('User:D41D8CD98F/append-support-info.js')</source></span> to [[MediaWiki:common.js]].

ping [[User:Cubbi]], [[User:Nate]], [[User:P12]], [[User:T. Canens]]

--[[User:D41D8CD98F|D41D8CD98F]] ([[User talk:D41D8CD98F|talk]]) 23:00, 10 April 2023 (PDT)
: I was just thinking that we should have a table like this another day. But I'm a bit worried about this implementation - it would generate API queries on every page.
: Also, when I tried this on {{lc|std::string_view}}, it also had rows for {{tt|optional}} and {{tt|any}}. How does it decide which rows to pick? [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 17:38, 13 April 2023 (PDT)
:: I noticed that API queries are cached for a month (due to the <code>cache-control: max-age=2592000</code> HTTP header), so I decided to make use of this, instead of making another layer of cache.
:: The script considers a row ''relevant'' if
::* It links to the current page, or to a parent of the current page.
::* It links to a header, and the current page is defined in that header (as indicated by the use of [[Template:dcl header]]).
::* The current page contains a table of feature-test macros. In this case, the script looks up in [[cpp/feature test]] to find out which papers are relevant, and picks every row in [[cpp/compiler support]] that links to one of these papers.
:: In the case of <code>string_view</code>, the script finds <code>__cpp_lib_string_view</code>, determines that P0220R1 is relevant, and shows every row that links to P0220R1. --[[User:D41D8CD98F|D41D8CD98F]] ([[User talk:D41D8CD98F|talk]]) 22:48, 13 April 2023 (PDT)

=== Invalid SSL certificate in es.cppreference.com===
Anybody knows what's going on?<br>
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 08:52, 18 April 2023 (PDT)

: Hi. No worries. Only [https://en.cppreference.com en], [https://de.cppreference.com de], and [https://zh.cppreference.com zh] are alive right now. All the others are down.) : --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 11:03, 18 April 2023 (PDT)

=== es.cppreference.com and other companion sites (French) have been trolled with "Best is Rust"===
The site is useless.  Can it be restored?<br>
[[User:Ljestrada|ticotico]] ([[User talk:Ljestrada|talk]]) 06:59, 2 August 2023 (PDT)
: I've restored some companion sites' main pages (not all yet). And now my IP (not the current one) seems blocked (erroneously). Space Mission. --[[Special:Contributions/23.106.56.37|23.106.56.37]] 03:57, 4 August 2023 (PDT)
:: Restored the remaining two --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 07:12, 4 August 2023 (PDT)

== Outdated autolinks ==

I've noticed that `std::format_string` isn't being autolinked at 
[[cpp/utility/format/format]]. Could the autolinker be updated? [[User:Ecatmur1|Ecatmur1]] ([[User talk:Ecatmur1|talk]]) 09:07, 19 September 2023 (PDT)

: You're so right. Identifiers should (and can) be updated. There are already several requests for this action.) You could take a look at the discussion [[#Feature Suggestion: Auto Header Link|above]].
: Ideally, to ensure the auto-links stay updated, new identifiers, along with their links, should be collected (as a standard procedure) immediately after a set of new pages are added...) --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 14:00, 19 September 2023 (PDT)

:: The situation with autolinks inside code blocks is now much better. The next step is to expand {{tl|lc}} GeSHi [[MediaWiki:Autolinker-definition-cpp|database]] for auto-linking within non-code parts of pages. --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 17:43, 11 October 2023 (PDT)

== Zapping {{attr|nodiscard}} from declarations? ==

I don't see why we need to have those annotations that have no normative effect. Implementations are free to warn, or not warn, whether or not the attribute is present. So they just make the declarations noisier and add to cognitive overhead if we have a standard diff where the only difference is the annotation (which it is in a lot of places). [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 16:23, 22 February 2024 (PST)

: If {{stddoc|P2422}} and {{stddoc|P3122}} are voted into the standard as DR, then we can strike out all of them. --[[User:Xmcgcg|Xmcgcg]] ([[User talk:Xmcgcg|talk]]) 18:06, 22 February 2024 (PST)

:: Full agreement with T. Canens, irrespective of the existence or acceptance of those papers --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 02:55, 23 February 2024 (PST)

:: Those papers are not particularly relevant. Even if the standard added nodiscard to every function declaration where MSVC has it, my opinion would not change. The attribute doesn't have any normative effect, and it's just noise from a documentation perspective. There are tons of incorrect ways to call a function, and discarding the result is almost always among the more benign of them - the behavior is still well-defined, after all. There's no reason to call out this particular form of mistake in the declaration - C++ declarations are hard enough to read already. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 17:08, 24 February 2024 (PST)

::: I agree with the direction. In fact, we can stop adding new <nowiki>[[nodiscard]]</nowiki> from now on. The worst case I am worrying about is that someone starts removing the existing <nowiki>[[nodiscard]]</nowiki>s but stops somewhere in the middle. For example, the {{c/core|constexpr}} additions are now presented in two ways: separate revisions and {{mark|constexpr since C++XX}} marks, and I have no clue whether the progress has ever been tracked.

::: If LWG can reach consensus in the Tokyo meeting (which is highly possible for {{stddoc|P3122}} becuase its author is the current LWG chair), I can handle the removal of all <nowiki>[[nodiscard]]</nowiki>s from the (non-experimental) standard library. --[[User:Xmcgcg|Xmcgcg]] ([[User talk:Xmcgcg|talk]]) 17:54, 25 February 2024 (PST)

== inconsistency in formatting exposition-only names in decl and other source code  ==

New names are introduced in recent standards and some of them are exposition-only which are not part of the interface to the user. However, there is inconsistency in their formatting across pages, particularly in the decl part, which doesn't align well:

{{dcl begin}}
{{dcl|notes={{mark expos}}|num=1|1=
class /* exposition-name */;
}}
{{dcl|notes={{mark expos}}|num=2|1=
class /* __exposition_name */;
}}
{{dcl|notes={{mark expos}}|num=3|1=
class exposition-name;
}}
{{dcl|notes={{mark expos}}|num=4|1=
class __exposition_name;
}}
{{dcl end}}

Is there a way to resolve this problem in unifying its format of naming or declaring exposition-only items? It would be nice if there is a template in wrapping such names inside dcl template to italicize it just like how {{tti|boolean-testable}} is automatically italicized on [[cpp/concepts/predicate]].

[[User:Cooky|Cooky]] ([[User talk:Cooky|talk]]) 19:42, 12 April 2024 (PDT)