Namespaces
Variants
Views
Actions

Talk:Main Page

From cppreference.com
Revision as of 20:50, 8 April 2023 by 172.70.250.188 (Talk)

Replacement filing cabinet.svg

Archives

Archive 1 Archive 2 Archive 3

Contents

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. 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 this page as expected in all browsers I have --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 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 (talk • contribs) 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 https://github.com/p12tic/cppreference-doc/issues 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)

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 es.cppreference.com in universities in Spain, Mexico. Latin America. ticotico (talk) 16:41, 19 March 2020 (PDT)

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)

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.

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 nullptr yields the nullptr_t result in the C section --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 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 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)

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)

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)

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)

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. 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.

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? 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 
** mainpage|mainpage-description
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 eyeball-searingly hideous default placeholder. -- 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? 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?

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)

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)

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

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

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

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

E.g. [[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. — 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.



ticotico (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


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)

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)

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)


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

Current:

(1)
basic_string();
explicit basic_string( const Allocator& alloc );
 (until C++17)
basic_string() noexcept(noexcept( Allocator() )) :

    basic_string( Allocator() ) {}

explicit basic_string( const Allocator& alloc ) noexcept;
 (since C++17)
(until C++20)
constexpr basic_string() noexcept(noexcept( Allocator() )) :

    basic_string( Allocator() ) {}

explicit constexpr basic_string( const Allocator& alloc ) noexcept;
 (since C++20)

Desirable:

Default (Diff) view:

(1)
basic_string();
explicit basic_string( const Allocator& alloc );
 (until C++17)
constexpr basic_string() noexcept(noexcept( Allocator() )) :

    basic_string( Allocator() ) {}

explicit constexpr basic_string( const Allocator& alloc ) noexcept;
 (since C++17)
(constexpr since c++20)

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

(1)
basic_string();
explicit basic_string( const Allocator& alloc );

<gadget-StandardRevisions> in C++17:

(1)
basic_string() noexcept(noexcept( Allocator() )) :

    basic_string( Allocator() ) {}

explicit basic_string( const Allocator& alloc ) noexcept;

<gadget-StandardRevisions> in C++20:

(1)
constexpr basic_string() noexcept(noexcept( Allocator() )) :

    basic_string( Allocator() ) {}

explicit constexpr basic_string( const Allocator& alloc ) noexcept;

I think the desirable presentation can be achieved by:

1. add .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.):

patch 
--- 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');

3. update all pages to use the new t-dcl-constexpr-before class.

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

--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 --Ybab321 (talk) 05:21, 12 June 2021 (PDT)
Bump <_<; --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 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)

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)

Searching for C++20 content.

Searching for coroutine_handle 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 --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 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.

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 std::format, and I noticed that the compiler version is different. Any clues?

ticotico (talk) 10:02, 15 January 2021 (PST)

Hi, Javier.
  • The std::format family is not implemented yet by gcc/clang (not sure about cl). To run the examples locally one can use the original fmt library, or better, use gotbolt online compiler choosing the fmt library from the list of additional libraries and compile with flag -std=c++20.
  • As to the cppreference's Online compilers, the following local discussion can shed the light on: 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 script (gadget) for English version. The same could be done for other languages/sites. For instance, on Spanish es.cppreference.com 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).

A Bonus: cppreference online compier version checker

Run this 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");
}
--Space Mission (talk) 13:01, 15 January 2021 (PST). Edited --Space Mission (talk) 08:57, 10 June 2022 (PDT)

TS section minor clean up - 2021.

Now, in 2021, when the work on merging Concepts TS and 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):


. . .

Technical specifications

Standard library extensions (library fundamentals TS)
. . .
Concepts TS (concepts TS) ← to be removed (?)
Ranges TS (ranges TS) ← to be removed (?)
Transactional Memory (TM TS)

These pages are (and will be) available via Technical specification page.

--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. --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. Tambre (talk) 22:32, 22 February 2021 (PST)
Feedback -- External search sucks Drankinatty (talk) 14:41, 24 February 2021 (PST)
If you do keep DuckDuckGo, it'd be nice if you could restore the access key for the search box. 77.182.132.128 07:07, 26 February 2021 (PST)
Can we PLEASE 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. 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. 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 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 operator<< of some class, e.g. basic_string::operator<<,>>().
    (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.)
-- 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) Drankinatty (talk) 14:37, 24 February 2021 (PST)

It looks like the issue is the box-sizing: border-box styling being applied to various page structural elements. The stanza in question looks like this, in the output CSS (when unminified): 
  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
  }
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 box-sizing: border-box rule and everything fits correctly again.
Here's a userstyle I just published to userstyles.org, which can be installed to fix the layout issue. -- 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. -- 70.54.171.187 10:17, 10 March 2021 (PST)
@IP User: Technically that's true, but mostly because border: inherit resets the border width of those elements to 0. At that point the box-sizing: border-box 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 2px (not 10) borders on the search elements. -- FeRDNYC (talk) 16:14, 10 March 2021 (PST)
I suspect that the CSS is from [1]. Is only Firefox affected? This looks fine in Chrome. 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? -- 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 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. 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. -- 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! -- FeRDNYC (talk) 21:42, 4 March 2021 (PST)

✔ Done. 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

✔ Done. --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? 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? --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 --Ybab321 (talk) 04:17, 1 June 2021 (PDT)
Yes. Filesystem TS pages are also questionable as people land on its pages from google. --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 __NOINDEX__ those pages instead of just deleting them (might need a server side change though)? T. Canens (talk) 14:20, 1 June 2021 (PDT)
Yea, libc++ ships the experimental::filesystem as well: /usr/lib/llvm-12/include/c++/v1/experimental/filesystem
So:
* bury the Ranges-TS due to the reasons listed above; (?)
* add __NOINDEX__ flag to pages that have standardized (merged-into IS) alternatives
--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. the page for <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?

-- 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 --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: 
  // 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;
(already not the most readable) instead becomes this, at zh.cppreference.com: 
  // 复合类型分类
  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;
Like I said, it's not super-readable even in the English verson, but the Chinese does seem far worse. -- 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 ticotico (talk) 15:24, 17 August 2021 (PDT)

Hi, ticotico!
✔ Fixed: read()/write() trickled down from somewhere, a la read(). .) --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.) --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 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 std::latch, I can see the link to the class (in blue) in the Engish version, but not in the Spanish version.
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?
ticotico (talk) 08:08, 19 August 2021 (PDT)

✔ Fixed: One of the templates was out of date. ticotico (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 :-)
ticotico (talk) 10:20, 26 October 2021 (PDT)

Install MediaWiki Extension:TemplateSandbox?

The MediaWiki standard 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 $wgTemplateSandboxEditNamespaces), 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! -- 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. --Nate (talk) 06:28, 29 October 2021 (PDT)
@Nate: The current version 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. This is the zipfile-download link for the revision tagged REL1_21, 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!") -- FeRDNYC (talk) 14:13, 29 October 2021 (PDT)
P.S> (I've updated the extension page to list the correct version requirements.) -- 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 :-)
ticotico (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:

type and its singleton object described in separate pages:

For example, in page cpp/memory/new, nothrow_t and nothrow are classified as a class and an object, however, destroying_delete_t and 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. 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, nothrow is what they see and write in C++ code, and nothrow_t is perhaps useful to understand an error message or when exploring a standard library headers. Similar to how std::to_chars_result has little use outside the context of cpp/utility/to_chars. --Cubbi (talk) 05:52, 18 April 2022 (PDT)
Agree. I propose as followed: Yaossg (talk) 23:46, 21 April 2022 (PDT)


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. 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. --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 --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.
ticotico (talk) 07:31, 31 March 2022 (PDT)

Doesn't seem like searchers actually have any requirements [2] --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 --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.

[3]

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:

[4]

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 --Ybab321 (talk) 02:27, 31 May 2022 (PDT)
The OP posted it on SO as a question, instead of looking at existing answers, and self-deleted since then to 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 --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 {{lc}} but got broken result, so I used {{c}} instead)

#include <string>

code "<string>" will become a link to cpp/header/string

--Yaossg (talk) 02:39, 28 August 2022 (PDT)

The auto-generated links are recorded here: MediaWiki:Autolinker-definition-cpp (which is generated from here). But this page has not been updated from Feb. 2021, and only Administrators can edit it. --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:
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).

#include <iostream>

Run this code
#include <iostream>
int main() { std::cout << "test\n"; }
--Space Mission (talk) 07:14, 28 August 2022 (PDT)

Mistakes in set

Just found that cpp/container/set has the following mistakes:

  • It mentions key_type, while 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 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

Yehezkelshb (talk) 12:10, 8 December 2022 (PST)

The standard citation you linked in your first point is regarding node_handle, which correctly specifies "map containers only" for key_type. I agree with your second point, and on that note, though the standard says set's iterator and const_iterator are both "constant iterators" (which means they don't model LegacyOutputIterator), but I would prefer if we wrote "iterator to const value_type", I don't think that's inaccurate. --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? Will eccles (talk) 15:02, 17 March 2023 (PDT)

There used to be an option accepting money directly on the support page, but now it's gone... I don't know. Maybe you can ask them through their email. 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. 172.70.250.188 21:50, 8 April 2023 (PDT)

Retrieved from "https://en.cppreference.com/mwiki/index.php?title=Talk:Main_Page&oldid=150283"