Talk:Main Page

Replacement filing cabinet.svg


Archive 1 Archive 2 Archive 3


[edit] 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 tuple constructor. It would be nice to be able to hide everything unrelated to C++17 <or some other> standard. — Preceding unsigned comment added by Hedede (talkcontribs) 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. --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? 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 made some notes on issues. T. Canens (talk) 13:15, 19 January 2018 (PST)
I wonder if we could put these issues to because it's so easy to lose them here. --P12 14:52, 7 June 2019 (PDT)
Please see cpp/17, cpp/20. --Costa (talk) 10:17, 15 December 2019 (PST)

[edit] 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? --Nate (talk) 10:05, 13 July 2016 (PDT)

I only heard bad things about the non-English cppreference as well. --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 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. --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 AWB bot set up to transform the piles of language links into {{langlinks}}, but if we are doing this then that should probably wait. 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... 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 in universities in Spain, Mexico. Latin America. ticotico (talk) 16:41, 19 March 2020 (PDT)

[edit] Tracking {{noexcept}} and hidden DR comments

We've decided - I think - on merging {{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 {{noexcept}} with a tracking template - say, {{unreviewed noexcept}} - which looks just like {{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 <!--CWG 1234-->-style DR markers, most of which probably should go to {{dr list item}}. 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. --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. 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. --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 {{noexcept}})? I'm not sure I see much point in keeping them. 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. :) --Nate (talk) 20:04, 1 April 2017 (PDT)

[edit] Exact match in search results

When searching, if there is only one hit the site automatically redirects to that page. (

When there are multiple results including an exact match, it does not automatically forward, although the exact match is listed on top. (

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.

Ragnar (talk) 04:25, 2 May 2017 (PDT) Ragnar

[edit] Wrong line breaking

On page c/language/operator_logical

See screenshot here:

[edit] 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)

[edit] Can you reword and similar pages...

... to avoid such: misunderstandings? (I am assuming that this interpretation of your docs is the correct one: - is this correct? )

[edit] Minor search bug

Searching for nullptr yields the nullptr_t result in the C section --Ybab321 (talk) 11:14, 25 November 2017 (PST)

[edit] gadget-StandardRevisions tool to be updated

<gadget-StandardRevisions> is indeed useful but the problem is that, for example 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.

[edit] 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.

[edit] P0777R1/decay/remove_cvref

P0777R1's changes from std::decay to 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 remove_cvref throughout even for pre-C++20 features.
  • Drop them and keep using decay for pre-C++20 features (keep remove_cvref for new features in C++20 and later).
  • Drop them and use remove_cv_t<remove_reference_t<...>> for pre-C++20 features

Thoughts? 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. --LittleFlower (talk) 18:35, 23 December 2017 (PST)

[edit] Should we have {{mark macro var}} or {{mark macro}}?

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

And some macros like and_eq and static_assert expand to keywords and operators, and not (constant) expressions. Is it inappropriate to classify them as (macro constant) ? And should a new template, such as {{mark macro}} (resulting in (macro)), be used for them?

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

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. Fruderica (talk) 08:54, 18 May 2018 (PDT)

[edit] Return the 'Operator precedence' to the main page

May someone do the subj.? Why have this link was removed, at all? Serge Roussak (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. --LittleFlower (talk) 19:57, 3 February 2018 (PST)

[edit] replace semicolon by comma as interval notation

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?--LittleFlower (talk) 17:35, 8 February 2018 (PST)

[edit] another minor search bug

When searching for "endian", you are directly forwarded to, which contains an enum value with "endian" in its name, but since C++ there is the enum endian: Search should either list both or go to the endian page. Gemini67 (talk) 23:34, 29 May 2018 (PDT)

[edit] finding rule of zero/three/five =

It would be nice to find the above page ( when searching for "rule of zero" or "rule of five". Currently only "rule of three" leads to a search result. 01:03, 12 August 2019 (PDT) André

[edit] Adding StandardRevisions and `` 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 `` 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? Peregringlk (talk) 02:36, 13 September 2019 (PDT)

[edit] Inconsistent capitalization


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? Gennaro Prota (talk) 11:41, 2 February 2020 (PST)

[edit] Redirecting from to automagically

While on the "Página Principal"in 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?

ticotico (talk) 13:34, 18 March 2020 (PDT)

The main page is like the one place you can't use {{langlinks}} :( T. Canens (talk) 20:22, 20 March 2020 (PDT)
Thx! ticotico (talk) 09:31, 21 March 2020 (PDT)

[edit] 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? Drankinatty (talk) 02:36, 4 April 2020 (PDT)

Until then, I highly recommend the 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: #content, #cpp-head-first, #cpp-head-second, #footer, .mw-geshi, .de1 { width: auto !important; } --Ybab321 (talk) 07:56, 4 April 2020 (PDT)

[edit] 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 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.) -- Radix (talk) 02:12, 12 April 2020 (PDT)

[edit] 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 one.) — Radix (talk) 15:50, 24 April 2020 (PDT)

[edit] Vector skin is missing the standard revision drop-down list.

Radix (talk) 19:00, 29 April 2020 (PDT)

[edit] A [[File]]'s image is served non-securely.

E.g. [[File:Imbox notice.png]] renders into an image with src="", i.e. HTTP, not HTTPS. — Radix (talk) 17:51, 30 April 2020 (PDT)

[edit] Searching in native language

If I try to search for a term in Spanish on, 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.

ticotico (talk) 14:04, 1 May 2020 (PDT)

[edit] 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:

C++ draft:

Defect report:

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

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.


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. --Cubbi (talk) 13:41, 16 June 2020 (PDT)

[edit] Acronym definition for SOCCC?

I found this acronym in the example for std::string operator+, but not its definition.
ticotico (talk) 09:28, 5 August 2020 (PDT)

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

[edit] 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 constexpr specified. I dislike how string ctor is presented, I like how tuple ctor is presented, and I propose we switch to the latter as a convention. Anyone care to weigh in on this? --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 (constexpr since c++20) --Cubbi (talk) 12:20, 9 August 2020 (PDT)

[edit] 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 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.
ticotico (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. T. Canens (talk) 09:45, 12 September 2020 (PDT)

[edit] Searching for std::regular yields std::Regular in the results

Needs to be corrected to std::regular.
If you can change it in other languages (e.g., Spanish search list), much appreciated. ticotico (talk) 08:20, 22 September 2020 (PDT)

[edit] Searching for C++20 content.

Searching for coroutine_handle yields nothing. Shouldn't it find ?

'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 --Cubbi (talk) 14:40, 16 October 2020 (PDT)

[edit] Several of the special mathematical functions have type inconsistent with description

I noticed that several of these functions have an IntegralType k parameter, but the description for k reads:

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

For example, comp_ellint_1

Since the function can be a function template, wouldn't Arithmetic k be a better fit?
ticotico (talk) 17:45, 22 October 2020 (PDT)

The discussion has continued here. This Note is especially enlightening.