Difference between revisions of "Talk:Main Page"
Drankinatty (Talk | contribs) m (Updated Proposal For Dark Mode request.) |
|||
(16 intermediate revisions by 11 users not shown) | |||
Line 189: | Line 189: | ||
Recently StackOverflow launched a Dark Theme(beta) that has been very well received and well implemented. They are currently taking making final tweaks to any of the pages that still have contrast issues, etc.. However, the dark-mode on SO has been brilliant. Eye-strain is greatly reduce which is one of the main benefits. Would Cppreference consider a similar addition of a dark-mode that would provide a choice between light and dark mode that the user could choose through their settings? [[User:Drankinatty|Drankinatty]] ([[User talk:Drankinatty|talk]]) 02:36, 4 April 2020 (PDT) | Recently StackOverflow launched a Dark Theme(beta) that has been very well received and well implemented. They are currently taking making final tweaks to any of the pages that still have contrast issues, etc.. However, the dark-mode on SO has been brilliant. Eye-strain is greatly reduce which is one of the main benefits. Would Cppreference consider a similar addition of a dark-mode that would provide a choice between light and dark mode that the user could choose through their settings? [[User:Drankinatty|Drankinatty]] ([[User talk:Drankinatty|talk]]) 02:36, 4 April 2020 (PDT) | ||
: Until then, I highly recommend the [https://chrome.google.com/webstore/detail/deluminate/iebboopaeangfpceklajfohhbpkkfiaa Deluminate] extension, it works great with cppreference, as well as Stack Exchange and more-or-less every other website I browse. Whilst we're at it, I propose adding a widescreen variant too, which I'm currently doing with Stylus with the CSS: {{tt|#content, #cpp-head-first, #cpp-head-second, #footer, .mw-geshi, .de1 { width: auto !important; } }} --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 07:56, 4 April 2020 (PDT) | : Until then, I highly recommend the [https://chrome.google.com/webstore/detail/deluminate/iebboopaeangfpceklajfohhbpkkfiaa Deluminate] extension, it works great with cppreference, as well as Stack Exchange and more-or-less every other website I browse. Whilst we're at it, I propose adding a widescreen variant too, which I'm currently doing with Stylus with the CSS: {{tt|#content, #cpp-head-first, #cpp-head-second, #footer, .mw-geshi, .de1 { width: auto !important; } }} --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 07:56, 4 April 2020 (PDT) | ||
+ | :: I recently looked for acceptable extensions for Firefox. All required excess privileges. Some, like "DarkView" requeted the ability to clear browsing history and delete cookies -- not what you would expect in a dark reader. Seems implementing a dark-mode by cppreference.com for the mediawiki interface would be the safest option -- even if it takes more time to implement. Four years on, this is still a needed addition. The StackOverflow dark-mode model is a good model to look at for implementation, colors, etc.. [[User:Drankinatty|Drankinatty]] ([[User talk:Drankinatty|talk]]) 21:04, 23 August 2024 (PDT) | ||
== Where are level 2 headings? == | == Where are level 2 headings? == | ||
Line 829: | Line 830: | ||
: You're so right. Identifiers should (and can) be updated. There are already several requests for this action.) You could take a look at the discussion [[#Feature Suggestion: Auto Header Link|above]]. | : You're so right. Identifiers should (and can) be updated. There are already several requests for this action.) You could take a look at the discussion [[#Feature Suggestion: Auto Header Link|above]]. | ||
: Ideally, to ensure the auto-links stay updated, new identifiers, along with their links, should be collected (as a standard procedure) immediately after a set of new pages are added...) --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 14:00, 19 September 2023 (PDT) | : Ideally, to ensure the auto-links stay updated, new identifiers, along with their links, should be collected (as a standard procedure) immediately after a set of new pages are added...) --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 14:00, 19 September 2023 (PDT) | ||
+ | |||
+ | :: The situation with autolinks inside code blocks is now much better. The next step is to expand {{tl|lc}} GeSHi [[MediaWiki:Autolinker-definition-cpp|database]] for auto-linking within non-code parts of pages. --[[User:Space Mission|Space Mission]] ([[User talk:Space Mission|talk]]) 17:43, 11 October 2023 (PDT) | ||
+ | |||
+ | == Zapping {{attr|nodiscard}} from declarations? == | ||
+ | |||
+ | I don't see why we need to have those annotations that have no normative effect. Implementations are free to warn, or not warn, whether or not the attribute is present. So they just make the declarations noisier and add to cognitive overhead if we have a standard diff where the only difference is the annotation (which it is in a lot of places). [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 16:23, 22 February 2024 (PST) | ||
+ | |||
+ | : If {{stddoc|P2422}} and {{stddoc|P3122}} are voted into the standard as DR, then we can strike out all of them. --[[User:Xmcgcg|Xmcgcg]] ([[User talk:Xmcgcg|talk]]) 18:06, 22 February 2024 (PST) | ||
+ | |||
+ | :: Full agreement with T. Canens, irrespective of the existence or acceptance of those papers --[[User:Ybab321|Ybab321]] ([[User talk:Ybab321|talk]]) 02:55, 23 February 2024 (PST) | ||
+ | |||
+ | :: Those papers are not particularly relevant. Even if the standard added nodiscard to every function declaration where MSVC has it, my opinion would not change. The attribute doesn't have any normative effect, and it's just noise from a documentation perspective. There are tons of incorrect ways to call a function, and discarding the result is almost always among the more benign of them - the behavior is still well-defined, after all. There's no reason to call out this particular form of mistake in the declaration - C++ declarations are hard enough to read already. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 17:08, 24 February 2024 (PST) | ||
+ | |||
+ | ::: I agree with the direction. In fact, we can stop adding new <nowiki>[[nodiscard]]</nowiki> from now on. The worst case I am worrying about is that someone starts removing the existing <nowiki>[[nodiscard]]</nowiki>s but stops somewhere in the middle. For example, the {{c/core|constexpr}} additions are now presented in two ways: separate revisions and {{mark|constexpr since C++XX}} marks, and I have no clue whether the progress has ever been tracked. | ||
+ | |||
+ | ::: If LWG can reach consensus in the Tokyo meeting (which is highly possible for {{stddoc|P3122}} becuase its author is the current LWG chair), I can handle the removal of all <nowiki>[[nodiscard]]</nowiki>s from the (non-experimental) standard library. --[[User:Xmcgcg|Xmcgcg]] ([[User talk:Xmcgcg|talk]]) 17:54, 25 February 2024 (PST) | ||
+ | |||
+ | == inconsistency in formatting exposition-only names in decl and other source code == | ||
+ | |||
+ | New names are introduced in recent standards and some of them are exposition-only which are not part of the interface to the user. However, there is inconsistency in their formatting across pages, particularly in the decl part, which doesn't align well: | ||
+ | |||
+ | {{dcl begin}} | ||
+ | {{dcl|notes={{mark expos}}|num=1|1= | ||
+ | class /* exposition-name */; | ||
+ | }} | ||
+ | {{dcl|notes={{mark expos}}|num=2|1= | ||
+ | class /* __exposition_name */; | ||
+ | }} | ||
+ | {{dcl|notes={{mark expos}}|num=3|1= | ||
+ | class exposition-name; | ||
+ | }} | ||
+ | {{dcl|notes={{mark expos}}|num=4|1= | ||
+ | class __exposition_name; | ||
+ | }} | ||
+ | {{dcl end}} | ||
+ | |||
+ | Is there a way to resolve this problem in unifying its format of naming or declaring exposition-only items? It would be nice if there is a template in wrapping such names inside dcl template to italicize it just like how {{tti|boolean-testable}} is automatically italicized on [[cpp/concepts/predicate]]. | ||
+ | |||
+ | [[User:Cooky|Cooky]] ([[User talk:Cooky|talk]]) 19:42, 12 April 2024 (PDT) |
Latest revision as of 20:04, 23 August 2024
Archives |
|
---|
[edit] 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.
- 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.
[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 (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)
- 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)
[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)
- 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)
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)
[edit]
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)
- 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)
[edit] 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
[edit] Wrong line breaking
On page c/language/operator_logical
See screenshot here: https://ibb.co/jc0DL5
[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 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? )
[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 (keepremove_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 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)
[edit] 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é
[edit] 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)
[edit] 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)
[edit] 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)
[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)- I recently looked for acceptable extensions for Firefox. All required excess privileges. Some, like "DarkView" requeted the ability to clear browsing history and delete cookies -- not what you would expect in a dark reader. Seems implementing a dark-mode by cppreference.com for the mediawiki interface would be the safest option -- even if it takes more time to implement. Four years on, this is still a needed addition. The StackOverflow dark-mode model is a good model to look at for implementation, colors, etc.. Drankinatty (talk) 21:04, 23 August 2024 (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 (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)
[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="http://upload.cppreference.com/mwiki/images/3/31/Imbox_notice.png", 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 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:
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: 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)
[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)
[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)
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() ) {} |
(since C++17) (until C++20) |
|
constexpr basic_string() noexcept(noexcept( Allocator() )) : basic_string( Allocator() ) {} |
(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() ) {} |
(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() ) {} |
||
<gadget-StandardRevisions> in C++20:
(1) | ||
constexpr basic_string() noexcept(noexcept( Allocator() )) : basic_string( Allocator() ) {} |
||
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)
[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 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)
[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)
[edit] 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
- --Space Mission (talk) 13:01, 15 January 2021 (PST). Edited --Space Mission (talk) 08:57, 10 June 2022 (PDT)
[edit] 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):
|
|
|
These pages are (and will be) available via Technical specification page.
- --Space Mission (talk) 11:01, 16 January 2021 (PST) 8 )
[edit] 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)
- 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...
[edit] 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 thebox-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)
- @IP User: Technically that's true, but mostly because
- 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)
[edit] 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)
[edit] 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)
[edit] 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)
- 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)
- Yea, libc++ ships the
- 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)
- Yes. Filesystem TS pages are also questionable as people land on its pages from google. --Cubbi (talk) 10:51, 1 June 2021 (PDT)
[edit] 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;
[edit]
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 laread()
. .) --Space Mission (talk) 17:16, 17 August 2021 (PDT)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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.
- @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
- 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)
[edit] [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)
[edit]
The descriptions of singleton object are treated differently.
type and its singleton object described in the same page:
- cpp/utility/in_place (the page is named after one of their singleton objects)
- cpp/memory/new/destroying_delete_t (the page is named after its class)
type and its singleton object described in separate pages:
- cpp/utility/piecewise_construct_t and cpp/utility/piecewise_construct
- cpp/memory/allocator_arg_t and cpp/memory/allocator_arg
- cpp/memory/new/nothrow_t and cpp/memory/new/nothrow
For example, in page cpp/memory/new, 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, andnothrow_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)
- cpp/utility/in_place remain unchanged
- cpp/memory/new/destroying_delete_t be renamed to cpp/memory/new/destroying_delete
- cpp/utility/piecewise_construct_t be merged into cpp/utility/piecewise_construct
- cpp/memory/allocator_arg_t be merged into cpp/memory/allocator_arg
- cpp/memory/new/nothrow_t be merged into cpp/memory/new/nothrow
- Helpers and similar functions maintain the status quo, for further discussion.
[edit] 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)
[edit] 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)
[edit] Localized compiler messages in examples
Is there a way to pass locale information to the compiler from the examples? GCC supports it.
[edit] 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)
[edit] 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.
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:
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?
- 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)
[edit] 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:
- for links in pages with tags like {{lc}} it is indeed MediaWiki:Autolinker-definition-cpp,
- for auto-linking inside Examples, synopses, source code (i.e. with tags like {{example}}, {{source}} etc), there is another list: MediaWiki:Geshi-keyword-list-cpp.
- I'm planning to participate in collecting most of new C++17/20/23 identifiers, when most of C++23 pages will be written (or earlier), and settling them in these two lists (as I once did before).
- --Space Mission (talk) 07:14, 28 August 2022 (PDT)
[edit] 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 saysset
'siterator
andconst_iterator
are both "constant iterators" (which means they don't model LegacyOutputIterator), but I would prefer if we wrote "iterator toconst value_type
", I don't think that's inaccurate. --Ybab321 (talk) 15:11, 8 December 2022 (PST)
[edit] 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)
[edit] 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)
[edit] Proposal: add User:D41D8CD98F/append-support-info.js for all users
User:D41D8CD98F/append-support-info.js is a script written by me. This script adds a section to the bottom of a page, which shows implementation support information relevant to this page.
Sample screenshots:
- cpp/language/delete: https://i.imgur.com/UdMLuUg.png
- cpp/language/data_members: https://i.imgur.com/m1pjJWG.png
- cpp/coroutine/generator/~generator: https://i.imgur.com/DknpcRD.png
- cpp/numeric/special_functions/ellint_3: https://i.imgur.com/33q4Guh.png
I believe that this script is useful for all readers, and thus should be enabled for everyone. AFAIK the simplest way to achieve this is adding importScript('User:D41D8CD98F/append-support-info.js') to MediaWiki:common.js.
ping User:Cubbi, User:Nate, User:P12, User:T. Canens
--D41D8CD98F (talk) 23:00, 10 April 2023 (PDT)
- I was just thinking that we should have a table like this another day. But I'm a bit worried about this implementation - it would generate API queries on every page.
- Also, when I tried this on std::string_view, it also had rows for
optional
andany
. How does it decide which rows to pick? T. Canens (talk) 17:38, 13 April 2023 (PDT)- I noticed that API queries are cached for a month (due to the
cache-control: max-age=2592000
HTTP header), so I decided to make use of this, instead of making another layer of cache. - The script considers a row relevant if
- It links to the current page, or to a parent of the current page.
- It links to a header, and the current page is defined in that header (as indicated by the use of Template:dcl header).
- The current page contains a table of feature-test macros. In this case, the script looks up in cpp/feature test to find out which papers are relevant, and picks every row in cpp/compiler support that links to one of these papers.
- In the case of
string_view
, the script finds__cpp_lib_string_view
, determines that P0220R1 is relevant, and shows every row that links to P0220R1. --D41D8CD98F (talk) 22:48, 13 April 2023 (PDT)
- I noticed that API queries are cached for a month (due to the
[edit] Invalid SSL certificate in es.cppreference.com
Anybody knows what's going on?
ticotico (talk) 08:52, 18 April 2023 (PDT)
- Hi. No worries. Only en, de, and zh are alive right now. All the others are down.) : --Space Mission (talk) 11:03, 18 April 2023 (PDT)
[edit] es.cppreference.com and other companion sites (French) have been trolled with "Best is Rust"
The site is useless. Can it be restored?
ticotico (talk) 06:59, 2 August 2023 (PDT)
- I've restored some companion sites' main pages (not all yet). And now my IP (not the current one) seems blocked (erroneously). Space Mission. --23.106.56.37 03:57, 4 August 2023 (PDT)
[edit] Outdated autolinks
I've noticed that `std::format_string` isn't being autolinked at cpp/utility/format/format. Could the autolinker be updated? Ecatmur1 (talk) 09:07, 19 September 2023 (PDT)
- You're so right. Identifiers should (and can) be updated. There are already several requests for this action.) You could take a look at the discussion above.
- Ideally, to ensure the auto-links stay updated, new identifiers, along with their links, should be collected (as a standard procedure) immediately after a set of new pages are added...) --Space Mission (talk) 14:00, 19 September 2023 (PDT)
- The situation with autolinks inside code blocks is now much better. The next step is to expand {{lc}} GeSHi database for auto-linking within non-code parts of pages. --Space Mission (talk) 17:43, 11 October 2023 (PDT)
[edit] Zapping [[nodiscard]]
from declarations?
I don't see why we need to have those annotations that have no normative effect. Implementations are free to warn, or not warn, whether or not the attribute is present. So they just make the declarations noisier and add to cognitive overhead if we have a standard diff where the only difference is the annotation (which it is in a lot of places). T. Canens (talk) 16:23, 22 February 2024 (PST)
- If P2422 and P3122 are voted into the standard as DR, then we can strike out all of them. --Xmcgcg (talk) 18:06, 22 February 2024 (PST)
- Those papers are not particularly relevant. Even if the standard added nodiscard to every function declaration where MSVC has it, my opinion would not change. The attribute doesn't have any normative effect, and it's just noise from a documentation perspective. There are tons of incorrect ways to call a function, and discarding the result is almost always among the more benign of them - the behavior is still well-defined, after all. There's no reason to call out this particular form of mistake in the declaration - C++ declarations are hard enough to read already. T. Canens (talk) 17:08, 24 February 2024 (PST)
- I agree with the direction. In fact, we can stop adding new [[nodiscard]] from now on. The worst case I am worrying about is that someone starts removing the existing [[nodiscard]]s but stops somewhere in the middle. For example, the constexpr additions are now presented in two ways: separate revisions and (constexpr since C++XX) marks, and I have no clue whether the progress has ever been tracked.
[edit] inconsistency in formatting exposition-only names in decl and other source code
New names are introduced in recent standards and some of them are exposition-only which are not part of the interface to the user. However, there is inconsistency in their formatting across pages, particularly in the decl part, which doesn't align well:
class /* exposition-name */; |
(1) | (exposition only*) |
class /* __exposition_name */; |
(2) | (exposition only*) |
class exposition-name; |
(3) | (exposition only*) |
class __exposition_name; |
(4) | (exposition only*) |
Is there a way to resolve this problem in unifying its format of naming or declaring exposition-only items? It would be nice if there is a template in wrapping such names inside dcl template to italicize it just like how boolean-testable
is automatically italicized on cpp/concepts/predicate.