# Talk:Main Page

##  Hiding previous versions of standard

Is it possible to hide everything unrelated to particular standard? It should be, bacause 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 https://github.com/p12tic/cppreference-doc/issues because it's so easy to lose them here. --P12 14:52, 7 June 2019 (PDT)

##  Using https?

Hello, I am working on embedding content from cppreference in an iframe displayed in a web app (The Jupyter notebook) for quick help reference. (i.e. ?std::vector yields the page on std::vector from cppreference). When Jupyter is served over https, browsers disallow loading content from an insecure source. Would it be possible for cppreference to be served over https?

(Note that some browsers also started highlightinf http as insecure in the address bar.)

It seems that cppreference is now served over HTTPS, but its stylesheets are not. This results in very ugly rendering in the browsers which block these non-secure resources. Can this be fixed, please ? 185.25.193.108 04:39, 11 February 2018 (PST) Cipri.Tom

I'm tired of the piles of repetitive interwiki links to other languages at the bottom of most pages, so I've made {{langlinks}}. {{langlinks|de|zh}} on a page named [[Foo/Bar/Baz]] is equivalent to [[de:Foo/Bar/Baz]][[zh:Foo/Bar/Baz]]. Up to 13 arguments are supported - which is the number of interwiki links on the main page.

The template User:T. Canens/xform interwiki can be used to transform existing interwiki link piles into {{langlinks}} invocations. It must be substituted. For example,

{{subst:User:T. Canens/xform interwiki|1=
[[ar:cpp/named req]]
[[de:cpp/named req]]
[[es:cpp/named req]]
[[fr:cpp/named req]]
[[it:cpp/named req]]
[[ja:cpp/named req]]
[[pt:cpp/named req]]
[[ru:cpp/named req]]
[[zh:cpp/named req]]
}}


becomes {{langlinks|ar|de|es|fr|it|ja|pt|ru}}. T. Canens (talk) 14:58, 22 March 2016 (PDT)

Great, that'll be useful. :) --Nate (talk) 06:24, 24 March 2016 (PDT)

##  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)

##  noexcept in declarations

A common complaint about cppreference is that noexcept is not part of the declaration (most recent one being this discussion on Lounge. Now that noexcept is part of function type, perhaps it makes even more sense to place them on declarations, in addition to the Exceptions section (complex noexcepts may say noexcept(/*see below*/). Comments? --Cubbi (talk) 17:53, 22 August 2016 (PDT)

This is a fair point. I think the original idea might have been an interest in avoiding a situation where we show too many technical details up front, possibly interfering with the presentation of more important information. Do we have any ideas about how much text would be added to declarations (i.e. would it just be appending the word "noexcept" in a few places, would it involve massive noexcept blocks all over the place, something in between, etc. :) --Nate (talk) 11:56, 23 August 2016 (PDT)
I wouldn't put massive blocks up top, cpp/utility/variant/swap can say noexcept(/*see below*/) up top and keep the existing noxcept block where it is, under Exceptions. --Cubbi (talk) 13:08, 23 August 2016 (PDT)
That seems pretty reasonable. --Nate (talk) 11:41, 24 August 2016 (PDT)
+1. I never quite understood why noexcept isn't in the declaration. T. Canens (talk) 15:13, 30 August 2016 (PDT)
I'll start rolling {{noexcept}} into the function declaration since there appears to be no objections. T. Canens (talk) 13:30, 10 March 2017 (PST)

##  http://en.cppreference.com/w/cpp/named req/AssociativeContainer

A LOT of broken templates on this page.... — Preceding unsigned comment added by 83.6.29.217 (talkcontribs) 03:53, 25 October 2016‎

Should be fixed now. Thanks! --D41D8CD98F (talk) 06:19, 25 October 2016 (PDT)

I'm adding references for the Ranges TS, and might not always be able to separate the "possible implementations" section from the implementation that I contribute to, which is licensed under Boost v1. My understanding is that a copy of the license needs to accompany the code.

Question open to License X for future referencing.

Cubbi gave a good answer over at Quora.com, but encouraged that I bring the question over here.

Cjdb (talk) 18:31, 28 January 2017 (PST)

I'd like to hear what others think. Mixing licenses is a headache (cppreference is dual-licensed under CC-BY-SA and GFDL) and I'd rather avoid it if at all possible, although Boost is permissive enough that I don't think compatibility is a problem. But if we have to do something like this, I suppose we can put a link to a license page somewhere, e.g., something like Second version[Boost licensed], roughly approximating the behavior of Wikipedia's image copyright tags. T. Canens (talk) 01:31, 29 January 2017 (PST)
Agree on all points. If at all possible, avoid putting copyrighted code here. It's completely fine to leave e.g. the possible implementations section blank for now if you can't fill it out -- perhaps someone else in the future will be in a better position to do that work. --Nate (talk) 08:20, 30 January 2017 (PST)

##  Why does c/io/ferror link to c/io/perror?

Ferror prints errors associated to this particular stream.

Perror prints errno.

These two functions seem unrelated, since they operate on error numbers from different sources.

Is strerror(ferror(stdin)) guaranteed to give meaningful results? If it is, I suggest to link to strerror instead of perror. If it is not, then why not remove this link at all?

Indeed, perhaps it was added just because it sounds similar? (like the two std::move or the two std::rename pages link to each other). In any case, I dropped it from the seealso in c/io/ferror. --Cubbi (talk) 06:00, 17 February 2017 (PST)
No, you didn’t c/io/ferror#See_also ;/ You dropped in from cpp/io/c/ferror, not from c/io/ferror
okay, done there too now.. This is a public wiki, you could help editing, too! --Cubbi (talk) 04:43, 18 February 2017 (PST)

##  Can I has rollback?

Is there a reason why not even admins have rollback rights? It's nice to be able to revert multiple utterly unhelpful edits with a single click. T. Canens (talk) 06:16, 9 March 2017 (PST)

##  noexcept on swap

If I understand it correctly, the pre-P0185R1 exception specifications of the form noexcept(swap(foo, bar)) were meant to pick up ADL'd swaps as well as std::swap. Of course they were all sorts of broken (see LWG 2554), but our depiction of them as using fully qualified std::swap doesn't seem correct either. Since we don't want to use std::is_nothrow_swappable to specify them, though, this is rather tricky. Any ideas? T. Canens (talk) 13:45, 10 March 2017 (PST)

Sure, just use std::iter_swap instead. --84.63.27.42 05:38, 4 June 2018 (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

I just made MediaWiki:Gadget-mathjax.js and {{mathjax-or}} after seeing the horrible rendering of {{mparen}} in Chrome and Edge (see cpp/numeric/random/negative_binomial_distribution for an example). Can anyone think of a reason why we shouldn't enable it (or something similar) by default? T. Canens (talk) 14:32, 3 July 2017 (PDT)

that looks great on the distributions. cpp/numeric/special_math could use some of that magic too. --Cubbi (talk) 08:37, 4 July 2017 (PDT)

##  RFC: should we rename "until C++XY" into "removed in C++XY"?

As noted most recently in the comments under https://stackoverflow.com/q/45013977 (but I think I saw this elsewhere), the way we describe revisions in dcl lists like

 template< class RandomIt > void random_shuffle( RandomIt first, RandomIt last ); (1) (until C++17) (deprecated in C++14) template< class RandomIt, class RandomFunc > void random_shuffle( RandomIt first, RandomIt last, RandomFunc&& r ); (2) (since C++11) (until C++17) (deprecated in C++14)

 template< class RandomIt > void random_shuffle( RandomIt first, RandomIt last ); (1) (deprecated in C++14)(removed in C++17) template< class RandomIt, class RandomFunc > void random_shuffle( RandomIt first, RandomIt last, RandomFunc&& r ); (2) (since C++11) (deprecated in C++14)(removed in C++17)

Or perhaps even pick a past tense verb to replace 'since' to match?

I am concerned about dsc lists, this kind of wording might look too bulky there:

 fun(C++11)(deprecated in C++14)(removed in c++17) description (function template)

--Cubbi (talk) 07:06, 11 July 2017 (PDT)

"added in"? I'm not that convinced that there's a problem. Like C++ we use half-open ranges. T. Canens (talk) 11:53, 11 July 2017 (PDT)
All right, looks like a decent number of people do hate "until". But the problem is that we currently use "until" for both changes and outright removals. "removed" works well for the second but not for the first.
Regardless, I think we should edit {{dcl}} to have "deprecated" as a first-class option, then audit all {{mark|deprecated in C++XX}} usages so that we can present the standard revisions in chronological order. T. Canens (talk) 13:04, 11 July 2017 (PDT)
chronological order is definitely a good step --Cubbi (talk) 13:22, 11 July 2017 (PDT)
OK, here's what I've implemented so far:
• {{mark until c++XY}} has gained an optional removed parameter; removed=yes causes it to render as (removed in C++11) rather than (until C++11).
• {{dcl}} has gained two parameters, deprecated and removed.
• deprecated is straightforward: it adds a "deprecated" marker after the "since" marker and before the "until" marker. deprecated=yes adds (deprecated); deprecated=c++XY adds (deprecated in C++XY).
• removed selects the version of the "until" marker to use. It can be yes or no. If not specified, defaults to no if deprecated is not present and yes otherwise.
• If until is not specified, then removed=X is a shorthand for until=X|removed=yes.
T. Canens (talk) 14:16, 14 July 2017 (PDT)

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)

##  Delete unused zh-version of pages

Could you delete some zh-version of pages listed here:

I guess that they will never be used again.

Fruderica (talk) 22:40, 26 November 2017 (PST)

All zapped. I don't visit zh regularly, so in the future please ping my en talk page. T. Canens (talk) 14:05, 27 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)

##  What you think of this example?

Such example is good for technical specification but probably too "technical" to appear in this part which shows practical use of the documented feature, and which is typically for an "applicative" example in other pages... I (personally) think it would be placed in description section and replaced by another example which shows use of remove_cvref in practical applications. This opinion also applies to other examples.

I would describe that as practical examples vs. unit-tests as examples. The description already said what remove_cvref does. The example illustrates how that description applies to several concrete cases, and that is useful for understanding the description. I sometimes edit such examples down to limit them to substantially distinct cases (there for example, remove_cvref_t<int&> doesn't add anything substantial to remove_cvref_t<int&&>). It's true that practical uses in examples bring value not already found in the description (e.g. my cpp/io/ios_base/register_callback#Example brings additional value to that page over simply calling register_callback and asserting that it was called, even though that example is larger than we'd like). If you have a concise, practical demo of remove_cvref as it would appear in code, by all means, edit it in. You could still leave a few lines of asserts in the same example to show how the description applies to a few specific types. --Cubbi (talk) 10:22, 20 December 2017 (PST)
Thanks. I agree with you that lots of what cannot be well described in words can be vividly shown by an example, which is "technical", like the asserts mentioned. Such examples meet users' demand of more details about the documented feature. They are completing the describing words. Users do also need practical examples. Practical examples and unit-tests shall be both placed, whose style of the page, however, will be like what? It does not seem right to simply place one after another in the section Example, for which gives readers a misconception that they are two similar examples that become strange to be merged together. I also thought of placing the "technical" one in the description section and as a part of the words describing the feature (how to organize?) and the practical one, as usual, in the section Example — by this way, the (originally) "technical" one became description in another way and the practical one integrates the feature into practice and shows ways it is used. More ideas? --LittleFlower (talk) 02:35, 21 December 2017 (PST)
It is indeed "description in another way". There are existing situations where such (unit-test style) examples are actually placed in the descriptions: this is common under cpp/language. For example, cpp/language/new has many micro-examples interspersed in the description. Under library references, the descriptions are typically short and followed by Parameters, Return, and Notes, and there is also some value in keeping all that visible at a glance: I've seen questions on stackoverflow that link to a cppreference page that could have been answered just by reading the Notes on that same page. Why is it strange to have different things shown in an Example though? cpp/algorithm/rotate#Example shows both a simple rotation to the left (effectively a unit test) and a simple rotation to the right (a popular trick) and an insertion sort (a practical use). Just comment before each part to say what it is for. --Cubbi (talk) 04:16, 21 December 2017 (PST)
Sorry! Apologize for I didn't think carefully before I leap. I did not check it carefully. --LittleFlower (talk) 22:59, 22 December 2017 (PST)

##  Wrong format

This section contains std::partial_sum two times. The m is left not bold.

not really, I saw all letters bold Yaossg (talk) 21:18, 1 January 2018 (PST)
Also, that bolding is done by MediaWiki directly. Even if it were somehow bugged, that's not something we can fix. T. Canens (talk) 12:49, 10 January 2018 (PST)
OK. I see. It is indeed left not bold on my browser (I checked it). Maybe it is my device bug.--LittleFlower (talk) 02:57, 11 January 2018 (PST)

##  Do you really mean this?

Well, I am pretty sure that you mean (Ci & Ci) != 0 and (Ci & Cj) == 0 instead of Ci & Ci != 0 and Ci & Cj == 0 in this section.--LittleFlower (talk) 01:57, 19 January 2018 (PST)

Not sure.but in fact, you ought to create talk page on its own place instead of here Yaossg (talk) 02:48, 19 January 2018 (PST)
Fixed. But yes, in the future please use the talk page of the page concerned (or just fix it yourself). T. Canens (talk) 13:16, 19 January 2018 (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)

##  containers on main page

A little while ago vector & map etc. were moved from the main page to go in a sub page. I frequently refer to these pages, but they're an extra click away. source_location, type_info & valarray get spots on the main page, but they're infrequently used. Calumr (talk) 01:52, 25 May 2018 (PDT)

Well, the three items you listed don't actually take up space that can be used by the containers...anyway, I've added direct links to a few containers. T. Canens (talk) 19:12, 26 May 2018 (PDT)

##  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é