Variants
Views
Actions

Cppreference talk:FAQ

From cppreference.com
Revision as of 23:12, 28 July 2024 by Studyingegret (Talk | contribs)

Contents

Grammer either/or

The line "Note, however, that you don't need to know neither of the complex templates, nor abovementioned guidelines in order to contribute" should read "Note, however, that you don't need to know either the complex templates, or abovementioned guidelines in order to contribute".

-P

Fixed, thanks! --P12 19:32, 7 August 2015 (PDT)
This is not yet fixed; it still says "neither" instead of "nor". Nwn (talk) 11:49, 13 April 2018 (PDT)

TR1?

Should we include information about TR1? -- Jaredgrubb 07:41, 2 July 2011 (PDT)

Fixed.P12 12:34, 2 July 2011 (PDT)
Neither TR1 (which is now obsolete of course) nor TR2 (far from finished, but already supported in small part (#include <filesystem>) by Microsoft, of all things) are curretnly mentioned on this page. --Cubbi 08:50, 30 April 2012 (PDT)

2011 C++ Standard

ISO/IEC 14882:2011 is now published. This page shouldn't be talking of drafts. Jonathan de Boyne Pollard 02:27, 24 March 2012 (PDT)

  • The linked draft is the latest publicly downloadable --Bazzy 02:51, 24 March 2012 (PDT)
    • That's complete rubbish. Aside from the fact that it isn't the latest draft at all but is over a year behind the actual latest draft, the URL of one of the places where members of the public can get a copy of the non-draft standard is right there, above. Jonathan de Boyne Pollard 07:11, 25 March 2012 (PDT)
We can't expect all editors to have a copy of the actual standard as it isn't freely available. Aside from that, the FAQ is surely outdated, thanks for pointing that out. -- P12 08:04, 25 March 2012 (PDT)
We should add the ANSI Store purchase link for C++11, which is 10 times cheaper than the ISO store currently linked: http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS%2FISO%2FIEC+14882-2012 --Cubbi 07:49, 25 July 2012 (PDT)
Good idea -- done. --Nate 13:07, 25 July 2012 (PDT)

C Reference

This page should be updated to mention the new C reference section of the site. --- Undeterminant 10:34, 22 April 2012 (PDT)

Updated. Thanks. -- P12 10:52, 22 April 2012 (PDT)
Might as well give the C11 ANSI store too (I can't seem to be able to edit this page). --Cubbi 12:08, 24 September 2012 (PDT)
I've relaxed the permissions for this page a bit; you should be able to edit it now, @cubbi. (@p12: we can go back to admin-only write-access for the FAQ if this was done on purpose -- I'm assuming that it makes sense for this page to have the same protection as e.g. the front pages.) Nate 15:57, 24 September 2012 (PDT)
There's indeed no reason why the page should be only admin-editable. -- P12 05:03, 25 September 2012 (PDT)

Broken links

The link to C++20 working draft should be replaced by link to n4868 https://isocpp.org/files/papers/N4868.pdf

Information about broken links on this website can be reported below

The link to the C17 draft PDF has been broken for a while. The PDF is still available via archive.org, so perhaps the link could be changed to that? https://web.archive.org/web/20180118051003/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

There are couple of links "std::terminate_handler" on the page http://en.cppreference.com/w/cpp/error/terminate that points to http://en.cppreference.com/w/cpp/error/terminated_handler instead of http://en.cppreference.com/w/cpp/error/terminate_handler

Thanks; looks like a typo in our syntax highlighter that was just fixed: https://github.com/p12tic/cppreference-doc/commit/bcb0271a87519c44b522563ddee7dccfd7c6830b. The next time we refresh, the page should be fixed. -Nate 11:25, 31 October 2012 (PDT)

The book version misses working links to CSS on some pages, e.g. std::search_n. --91.96.47.34 12:06, 4 June 2014 (PDT)

Not exactly a broken link, but the URL "http://en.cppreference.com/w/cpp/language/implicit_cast" is misleading. There is no such thing as an "implicit cast"; a cast is an *explicit* conversion. The page itself correctly refers to "implicit conversions". I suggest renaming that page to "implicit_conversion" and making "implicit_cast" link to it. (Removing the existing URL would cause problems.) Keith Thompson (talk) 09:03, 1 April 2016 (PDT)

yes, indeed the content of the page doesn't match the URL.. renamed leaving a redirect, thanks. --Cubbi (talk) 12:45, 1 April 2016 (PDT)

Not a broken link, but a non-existent link. The autolinker doesn't appear to have an entry for "std::scoped_lock", so most references to it don't have links. For example: http://en.cppreference.com/w/cpp/thread/mutex#Notes Nwn (talk) 12:00, 13 April 2018 (PDT)

NULL links are the same for both languages here https://en.cppreference.com/mwiki/index.php?title=Special%3ASearch&search=null&button=. NULL for C language should reference https://en.cppreference.com/w/c/types/NULL and not https://en.cppreference.com/w/cpp/types/NULL.

This seems to have been fixed some time ago. At least currently the links look fine in the search page. --178.162.222.163 01:04, 28 June 2020 (PDT)

Also not really a broken link, but more like missing links. free() tries to link against aligned_alloc(), but fails to do so. I debugged this a bit and found out that {{rlp|aligned_alloc|aligned_alloc}} seems to work. The linking mechanism employed there is the {{lc|...}} template, which is using an autolinking technique according to its documentation, but the C Autolinker definition page seems to be missing stuff like aligned_alloc(). I'm pretty sure that adding it there would make the linking work, but there are multiple obstacles to that:

  • the page is protected, so I cannot change it
  • I don't know whether it's maintained manually or programmatically
    • programmatically would mean that any changes would be in vain anyway until the generator or input data is fixed.

Additionally, this might be just one specific instance of links missing, maybe more C11 functions are not properly... uhm... indexed.

Anyone in for taking care of that? -- 217.92.117.31 07:06, 27 June 2020 (PDT)

The cpplang slack channel is returning a 404. Found on https://en.cppreference.com/w/Cppreference:EditingHelp.

Something is generating the occasional bogus link. For instance, https://en.cppreference.com/w/cpp/ranges#Helper_concepts. The link for ranges::iterator_t points to <a href="http://en.cppreference.com/w/cpp/ranges-ranges-placeholder/iterator_t">. Note that is in the raw html. If you hover over the link with a mouse, apparently the JS fixes is up. If you view the source, you can see the bad link, both in terms of path AND using plain http. And of course, this breaks non-JS browsers like wget and lynx. Nexushoratio (talk) 16:22, 11 July 2023 (PDT)

IIRC, this is a consequence of a workaround necessary for transition from PascalNames used in early concept proposals to standard_case names. --Space Mission (talk) 11:13, 12 July 2023 (PDT)

The cppreference.com/store link appears to be broken.

CSS

The limitation width and max-width for the whole page should be removed. I have located 3 of them in the latest HTML-Book-Version, files common/loadfe52.css and common/load7fe1.css. After removing them the pages look much better. My download of the offline version some months ago had the same "bugs". 80.147.4.22 02:49, 4 June 2014 (PDT)

Are you concerned about the width settings for the HTML-book-version or the live site (or both?) --Nate (talk) 06:53, 4 June 2014 (PDT)
All 3 versions, book, Raw and live, have text bodies with fixed width (and centered). At least the non-book versions should have variable width as recommended by W3, I think. Why killing one of the most reasonable features of HTML for nothing? --91.97.19.47 11:45, 4 June 2014 (PDT)

The css Mediawiki:Common.css for languages other than english is not up to date. Would you please synchronize them to the english version? Hiroo (talk) 00:09, 26 May 2015 (PDT)

There is a problem with http://en.cppreference.com/w/cpp/atomic/ATOMIC_FLAG_INIT it does not render correctly.

Boost Documentation?

According to the FAQ:

Some boost libraries could also be candidates for inclusion though. While their tutorials are very good, the reference documentation is often very inflexible and inconvenient.

I feel the same way, and every C++ programmer I've spoken to about Boost seems to say the same thing. I really think the inclusion of popular Boost libs on cppreference.com would be incredibly useful to the community.

Is there some way we can come to a consensus on this issue? I realize this would mean a scope change for this wiki, which would raise the question about other external libraries being documented here. From an OOD standpoint, I can see the elegance of restricting the scope of this site to the pure language standards, so perhaps this is a case for a new open source library reference wiki?

CStubing at EFNet 10:55, 31 December 2012 (PST)

Personally, I find their tutorials to be lacking compared to the documentation, but I've been using Boost for many years so I guess I got used to it. I agree that simple examples like the ones we put for standard C++ components would be useful (making a small flood-filled .PNG file with Boost.GIL is two lines, but there is no tutorial that shows how. People see the wall of text about generic algorithms and move on to other libraries). There's still a lot of redlinks in standard C++ library, though. --Cubbi 11:29, 31 December 2012 (PST)
I like this idea. I suspect that the missing piece for getting boost on cppreference.com is finding a person to lead an initial push to get the overall structure of boost docs figured out. The three main issues that I can think of are:
  • boost is big: I don't have good numbers on this, but based on the sources for boost_1_52 and libstdc++-v3, I'd say boost might be 2-3 times the size of libstdc++. That's a lot of content to cover.
  • boost is released more frequently: I'm not entirely satisfied with the way that we're handling versioning on the existing wiki, and any problems that we currently have involving multiple versions are going to be magnified for boost.
  • boost is copyrighted (?): We have to check any possible licensing issues, especially if we're interested in importing any of the existing boost tutorials or reference material.
If we can find satisfactory answers to those issues, I think we could start building a boost section similar to /w/c and /w/cpp. --Nate 11:22, 1 January 2013 (PST)
A couple of thoughts:
1) IMO it's hardly possible to cover all boost libraries in the foreseeable future unless there's a lot of new contributors. A possible solution would be to allow all contributions, but only show the libraries in the main page once the documentation is actually useful -- i.e. sufficiently documents most popular functionality, etc.
2) This problem will be hard to solve. An additional problem is that boost is not backwards compatible in quite a lot of cases. Some libraries have had major overhauls and it's hardly possible to document them without completely separating the documentation for each version of the library.
3) Most of the documentation is distributed under Boost software license, which is a BSD-like license -- we can do anything we want if we include the copyright text somewhere. A note on the main page of each library should be sufficient.
P12 09:50, 2 January 2013 (PST)

Too strict introduction

I think that the following text in the FAQ is overly strict.

Unfortunately this means that being a good educational resource is not among our objectives. It is assumed that the reader has good knowledge of C and/or C++. As a consequence, a lot of things, e.g. tutorials, comments about usage cases of one feature or another, detailed explanations of things that are implicitly clear to an experienced programmer, etc., are not included and should not be added. Basically, we try to keep things simple and clear for a programmer looking for reference of a feature he already knows.

When I wrote this some time ago I wanted to prevent the mess that appeared in some pages of the old Dokuwiki based cppreference.com website. It seems that there's little chance for that happening now, so I've relaxed the above guideline. P12 10:17, 2 January 2013 (PST)

Looks peachy. --Nate 17:45, 2 January 2013 (PST)

Reference to c++ standard

I think, maybe it is a good idea sometimes add a link to the c++ standard ISO/IEC 14882? Like this: 8.3.6 Default arguments (1-2,4) or like this [dcl.fct.default](1-2,4). Ruslo 00:09, 19 August 2013 (PDT)

This could be an useful bit of information. We could list all sections of the standard(s) the information of a particular page is derived from. It could be put into the references section, for example:

References

  • C++11 standard (ISO/IEC 14882:2011): 8.3.6 Default arguments [dcl.fct.default] (p. 1-2,4)
Or (hypothetical)

References

  • C++11 standard (ISO/IEC 14882:2011):
  • 8.3.5 Functions [dcl.fct]
  • 8.3.6 Default arguments [dcl.fct.default] (p. 1-2,4)
  • C++98 standard (ISO/IEC 14882:1998):
  • 8.3.5 Functions [dcl.fct]
  • 8.3.6 Default arguments [dcl.fct.default] (p. 1-2,4)
For consistent formatting, we could optionally use templates, for example: 
===References===
{{ref std c++11}}
{{ref std | section=8.3.5 | title=Functions | id=dcl.fct}}
{{ref std | section=8.3.6 | title=Default arguments | id=dcl.fct.default | p=1-2,4}}
{{ref std c++98}}
...
Note, that adding this information on all pages is a lot of work, thus I'm unsure whether this initiative is worth pursuing until there's a volunteer willing to spend some time adding this information to a major part of the wiki (say 1000 pages out of ~3000 total, this would take ~10-15 hours). P12 05:56, 19 August 2013 (PDT)
Yes, I argee. It's a lot of work, but I think it's not the main goal. Like examples - hack something, if you feel it can be improved and save it (to others and to youself). The goal is not to lose some link searching work. Ruslo 07:10, 19 August 2013 (PDT)
Second version is looks very nice and solve versioning problem. Ruslo 07:10, 19 August 2013 (PDT)
Any other opinions? P12 05:56, 19 August 2013 (PDT)
I think references (and </references>) sections are a good thing. As a formerly active Wikipedia editor, I would even enjoy seeing proper citation templates in use ( like http://en.wikipedia.org/wiki/Category:Citation_Style_1_templates ). It's true that it would be boring to go over all (or even the most popular thousand) of the existing pages, but if there is a standard way to do it, I, for one, would add a reference section whenever I edit a page.. --Cubbi 06:24, 19 August 2013 (PDT)
I like it, assuming:
  • ...it's not too much work to create a ref template.
  • ...it's placed at the bottom of pages, because (a) that's where references typically are found and (b) casual users of the site are probably more interested in the API and examples.
  • ...we can come up with a way of specifying references that isn't too complicated. I like the ref template proposed above. Cubbi, can you give an example of what "proper citation templates" might look like? --Nate 07:41, 19 August 2013 (PDT)
I meant like {{cite ISO|number=14882|year=2011|title=|sectionname= |section=|paragraph=}}, which could be used with other standard documents referenced: ISO 9599, 10646, 10967, 60559, Ecma 262, and which could then be wrapped in <ref> tags to mark specific sentences and to pop up in </references> (which is already supported here). --Cubbi 08:27, 19 August 2013 (PDT)
So the {{ref}} template could generate <ref>-based output, which could be displayed in a references section using </references>? Do you think that the built-in references stuff that mediawiki has would allow us to selectively display references for C++98, C++11, etc.? (Eventually it would be neat to have a javascript-based drop-down menu that selects what standard version a given page displays.) --Nate 13:22, 19 August 2013 (PDT)
Selective display and renumbering of references would be doable even with <ref> based system. However, I'd prefer a simple text/template approach -- this way only the end of the page source would contain reference definitions and the main text would not be cluttered. This is especially useful on templated pages, since e.g. Template:cpp/container/insert would need to use {{#switch: and describe different sections of the standard for different containers. Also, we're not Wikipedia, it's probably not very useful to put a citation near each sentence or paragraph -- most of the pages here are quite short and describe a very specific subject, thus it's usually obvious which citation is for which paragraph. The exception is, of course, the description of C and C++ languages (cpp/language/*) -- <ref> is useful there.
By the way, {{cite ISO|number=14882|year=2011|title=|sectionname= |section=|paragraph=}} could be short-circuited to something like {{cite std c++11|title=|sectionname=|section=|paragraph=}} as it's hard to remember the exact ISO standard number. Proper templates could be used for the rest of references.
P12 06:11, 20 August 2013 (PDT)
Okay, after giving it a bit more thought, I do agree that overwhelming majority of pages on this wiki have just one source (with versions that some day could become user-preferences/tabs), so general-purpose wikipedia approach isn't suitable. --Cubbi 07:01, 20 August 2013 (PDT)
FYI I've created the templates for the references section. Documentation is here. --P12 12:28, 23 September 2013 (PDT)

Bug with the Coliru editor

There seems to be a bug in where if I enter in a macro definition, say for example:

Run this code
#define size mysize

In a few seconds the compiler will change it to this

Run this code
# Define  you in mysiz

I've only found it to be doing this when I enter in size as the macro name and use a 6-letter alphabetic definition like the above. Try it yourself and you will see.

I'm not sure how to reproduce this. When I run your first example, all I get is a bunch of linker errors complaining about a missing main function -- but the #define remains intact. When I add a main, it compiles and runs without modifying main. Did you see this behavior with a specific compiler? --Nate (talk) 06:48, 14 April 2014 (PDT)

Which revision of the C Standard does this reference adhere to?

Since you request in the FAQ that differences between C89, C99 and C11 should be marked as such, would it be worthwhile to mention that n1256 describes C99 and that n???? describes C89? Newatthis (talk) 11:55, 15 July 2014 (PDT)

It is worth mentioning that n1256 is a freely-available final draft of ISO/IEC 9899:1999/Cor.3:2007(E), which was the last revision of C99 (see History of C for the list of major and minor revisions of C). The final draft for C89 was X3J11/90-013 (ANSI numbering) or n119 (WG14 numbering), although I am not sure if it can be found for free. --Cubbi (talk) 16:18, 15 July 2014 (PDT)
I inserted a link to n1256 and included the doc numbers for C89. At iso.org, I found ISO/IEC 9899 entries listed among the withdrawn documents. Newatthis (talk) 07:17, 16 July 2014 (PDT)
The most recent draft of the C11 standard is N1570. ansi.c.txt is a plain-text draft of the 1989 ANSI C standard; the 1990 ISO C standard differs from ANSI C only in the addition of some boilerplate material and some renumbering of sections. Keith Thompson (talk) 08:57, 1 April 2016 (PDT)
Right, this page links to n1570 for C11 (since 2012). As for that particular ansi.c.txt, it differs from the published standard in the number of max seconds in tm's tm_sec (draft says 61, standard says, erroneously, 62). Are there no other differences? --Cubbi (talk) 12:42, 1 April 2016 (PDT)

Conversion Constructors

Please create a page for Conversion Constructors

thank you for being bold and creating it yourself. --Cubbi (talk) 16:35, 22 September 2014 (PDT)

Search to redirect on exact match ?

I'm not sure where to post this, but it would be cool if e.g. http://en.cppreference.com/mwiki/index.php?title=Special:Search&search=std::basic_string redirected to its exact match http://en.cppreference.com/w/cpp/string/basic_string. Hopefully the idea hasn't been dismissed before, sorry if that's the case. Best, Nick

Typo

There's a typo in the page: "not publicly availbale".

indeed there was, corrected. --Cubbi (talk) 06:58, 14 September 2016 (PDT)

std::lower_bound description semantics - error?

On the description page for lower_bound, it says:

Returns an iterator pointing to the first element in the range [first, last) that is not less than (i.e. greater or equal to) value.

I always assumed the '[...)' bracket form indicates an inclusive/exclusive interval, suggesting that end(), for example, is never a possible return value. However, a little later the page says:

Iterator pointing to the first element that is not less than value, or last if no such element is found.

While it may be claimed that the brief overview is nothing without the rest of the page, I would like to modify the brief statement to include the fact that last will be returned if no such element is found.

However, I didn't want to edit it without seeking input. Thanks for your time!

Ringobelingo (talk) 08:10, 2 June 2017 (PDT)

this discussion would work better on Talk:cpp/algorithm/lower_bound. A copy of last serves as an error code, but it's not part of the range on which std::lower_bound (and all standard arlgorithms) operates: the range denoted by an iterator pair is always [first,last), excluding last. There is no error in the semantics, but an omission: it doesn't say what happens if there is no such element. I suppose it can be added as a second sentence ("If no such element is found, returns last."). ---Cubbi (talk) 09:19, 2 June 2017 (PDT)
Agreed. Thanks Cubbi. I shall claim first-post nerves :) --Ringobelingo (talk) 11:44, 2 June 2017 (PDT)

Compiler examples are not running

I thought that I'd test an example in distance, but all it did was say "Building and running..." in the output. This is not universal (some examples work where others do not), so there must be something partially broken in the link between this wiki and the Coliru online compiler. Can someone look into it please? Thanks.

Adrian 11:13, 5 June 2018 (EDT)

Coliru doesn't support HTTPS, so if you are accessing cppreference via HTTPS it doesn't work. T. Canens (talk) 09:02, 5 June 2018 (PDT)
I've reached out to the Coliru people, and they're gonna try to enable HTTPS support asap. --Nate (talk) 07:59, 28 June 2018 (PDT)

A little edit proposal

I propose changing the paragraph

Check out the following collections of links [1] [2] for alternative links and material that falls outside of the scope of this site.

to the text

Check out the collections of links for C and C++ for alternative links and material that falls outside of the scope of this site.

It's cleaner and clearer. - 37.113.168.36 21:20, 10 September 2018 (PDT)

const on non-static member function

Should https://en.cppreference.com/w/cpp/keyword/const link to https://en.cppreference.com/w/cpp/language/member_functions#const-.2C_volatile-.2C_and_ref-qualified_member_functions ? 2A0B:F4C1:0:0:0:0:0:6 15:28, 15 September 2018 (PDT)

sure. Done. --Cubbi (talk) 18:49, 15 September 2018 (PDT)

Search on site

Don't know where else to report this: search for "is_rvalue" on this site does not propose "is_rvalue_reference". It shows "There were no results matching the query". Search for "minma" does propose a lot of partial matches, e.g. "minmax". -- Valiko (talk) 12:58, 7 January 2020 (PST)

Same goes for "bind_front", which does not result in any matches.

Same for "midpoint" and "std::midpoint". Nothing found for both while std::midpoint should have been returned. Does anybody know when/how this search index is build? elbarto (talk) 12:37, 8 July 2020 (PDT)
According to Special:Version, search on the site uses a custom MediaWiki plugin written by P12 himself. Its source lives in a github repo, p12tic/CppSearch — the last commit that changed any code was in 2014.
According to the readme file...
The engine is very simple - it doesn't analyze the content of the wiki at all. Instead, it fetches the search keyword list from one or more special files in MediaWiki: namespace and only matches search queries to the entries in that list.
Part of me thinks that approach may have worked in 2012, but questions how sustainable it is today. Nevertheless, it's how things work.
For C++ that special file is MediaWiki:Cpp-search-list-cpp. Sure enough, the reason the items raised here don't come up in search is, none of them are on the list. (Add operator<< as well. Someone brought that one up back in 2017, in the only issue ever opened at the github repo.) -- FeRDNYC (talk) 07:35, 6 January 2021 (PST)
The case of operator<< in particular is actually a funny one, because most of those are on the list. The search issues seem to come down to:
  1. Search only shows the first page of matches, no matter how many there are. So, searching for just "operator" misleadingly makes it seem like there are hardly any operator<< entries — there are, they'd just be later in the results. There's no way I can find, though, to narrow the search beyond 'operator' in a way that still matches 'operator<<'.
  2. You can't search for the literal string 'operator<<' because '<' is a special character, prohibited in things like URLs and queries. (That's also why the operator pages have names like operator_ltlt2, and why I'm being careful to type 'operator&lt;&lt;' here.) Some of the templates on the site escape special characters, which is why that page's code can start off with just a literal {{title|operator<<}}, but if there's no template involved then something else has to do the escaping. For search, that's either broken or was never put in place.
  3. Because the strings in Cpp-search-list-cpp are unescaped, you can't search for things like 'operator_ltlt' or 'operator lt' — you'll only get lots of matches like std::atomic<T>::operator T.
-- FeRDNYC (talk) 08:08, 6 January 2021 (PST)
Thank you FeRDNYC for the reply and your research.
-- Valiko (talk) 12:10, 6 January 2021 (PST)
I got here to report the issue with searching for "midpoint" (already reported by elbarto above). There are no special characters, so what's blocking it from being added to the search list page? I'd do it myself, but there's no edit button on that page. Tomerv (talk) 10:28, 14 September 2022 (PDT)
The mediawiki search has been abandoned due to maintenance burden and has been for a fair while now. The replacement duckduckgo search finds midpoint just fine --Ybab321 (talk) 14:27, 14 September 2022 (PDT)
I agree that duckduckgo search works fine, but on the other hand DDG's bang feature actually uses the mediawiki search. So if I go to duckduckgo.com and search for "!cpp midpoint" I get directed to [1]. Maybe someone needs to ask DDG to change how "!cpp" bang works? Tomerv (talk) 23:02, 6 October 2022 (PDT)

Benio's questions

Hey, I am using cppreference at daily basis both at home and work, and joined to give something from myself. I believe I am experienced enough to give more benefits than loses by my contributions. However, I've found some inconsistencies across pages and wanted to clear that out before continuing.

{{mark}} annotations

Current practice

  • Attribute specifier sequence (since C++11)
    • ✅ The title is marked with "(since C++11)"
    • ✅ The syntax entry "[[ attribute-list ]]" is marked with "(since C++11)"
  • alignof operator (since C++11)
    • ✅ The title is marked with "(since C++11)"
    • ❌ Syntax entry is not marked with "(since C++11)"
  • Move assignment operator (since C++11)
    • ❌ The title is not marked with "(since C++11)"
    • ✅ All syntax entries are marked with "(since C++11)"

Desired convention

So what's the convention? For example, if we have a page about a (C++11) feature, should we:

  • mark both the title and all (C++11) features
  • mark the title and don't mark any (C++11) features
  • don't mark the title and mark all (C++11) features

Description pattern

Current practice

In order to increase readability, only the "example", "keywords" and "notes" sections are taken into account.

Note: this ↑ order is preferable.--Space Mission (talk) 11:30, 14 September 2022 (PDT)
Note: updated to the order presented in the item above.) --Space Mission (talk) 11:30, 14 September 2022 (PDT)
Note: this ↑ page is too complex to follow the simple pattern "notes" → "keywords" → "example". --Space Mission (talk) 11:30, 14 September 2022 (PDT)

Desired convention

The Manual of style provides incomplete description pattern, and covers classes and functions only.

  • What's the desired description pattern for sections missing in the Manual of style?
  • What's the desired description pattern for other pages?

{{langlinks}}

Spaces before {{mark}} and {{cmark}} annotations

— Benio (talk) 11.01.2022 20:31:19‎ (UTC)

much of these details emerge as informal implicit agreement between active editors, and there's always a thousand things to do to improve content before polishing formatting. It's low priority. Informally, i'd say this reasoning applies (mostly commenting to advertise the gadget):
  • regarding version marks, when used on list entries, their (weakly-implemented) goal is to support version selection (did you enable StandardRevisions?), so that list items can appear and disappear depending on the choice in the standard revision pull-down tab. When/if that works, a page describing something that began in C++11 with every line marked C++11 would awkwardly show an empty list when C++98/C++03 is selected, followed by other content; I'd say title mark is enough to set the baseline for a page, and body/lists should only mark changes that came later.
  • place of "keywords" in section order was indeed never pinned down. It links to other uses of the keywords described on the page, so it serves as part of navigation, like a specialized See Also - thus I'd put it just before that.
  • langlinks are only really useful when they link to hand-written translations, which is when the people who did the translation tend to update them.
  • space before mark? I didn't know they could matter. --Cubbi (talk) 14:29, 11 January 2022 (PST)
Thanks! I didn't know about this gadget. I shall enable it for sure. — Benio (talk) 11.01.2022 22:57:46 (UTC)

<assert.h> and <errno.h> go to same link

Hello,

The link for assert.h and errno.h contain the same link on this page:

https://en.cppreference.com/w/c/header

Is there supposed to be a separate page for the assert.h header?

The linked page covers both headers, nothing wrong with that --Ybab321 (talk) 02:11, 18 November 2022 (PST)
My dream is to create separate pages with synopses for all standard C-headers in "C"-part of cppreference, as it was already done for all C++ headers pages. Of course, if this is relevant for C. And desirable. But only after all main C++23/C23 pieces are added here. --Space Mission (talk) 12:40, 19 November 2022 (PST)

References to proposals

What do you think about adding proposal links into the References blocks of some library entities? From the library user's POV, there are primarily useful because of their Motivation sections. For example, in C++ Weekly - Ep 374 Jason complains about the difficult-to-grasp out_ptr page. It's easier to just reference https://wg21.link/p1132 there than to manually create motivating examples.

I'm not against it at all, that's kinda being done via the compiler support page. However, I would comment that, if I'm being honest, the motivations presented in papers are usually pretty weak, and I'd rather the work spent on adding these references was instead simply spent on writing an example or otherwise improving the page, or even just added a point to the talk page. --Ybab321 (talk) 10:17, 3 May 2023 (PDT)

Latest C++20 draft standard

N4860 was stated to be the final working draft version of C++20 until June 2021, when the following edit was made:

https://en.cppreference.com/mwiki/index.php?title=Cppreference:FAQ&diff=130272&oldid=127712

The FAQ now states that N4861 was the latest working draft. No source was cited at any time for either of these being the latest C++20 draft - can someone give reasons why either of these should be considered the latest C++20 draft (and why N4861 should or shouldn't be considered the first C++23 working draft?) Please provide citable sources! Ajm 80386 (talk) 08:05, 22 September 2023 (PDT)

I've looked into this. According to N4859 (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4859.html), N4860 is considered to be the final draft of C++20, and N4861 to be the first working draft of C++23. It's almost a moot point though, as the source states:
> The contents of N4860 and N4861 are identical except for the cover sheet, page headers and footers, and except that N4861 does not contain an index of cross references from ISO C++ 2017. Ajm 80386 (talk) 09:13, 22 September 2023 (PDT)
Oh, that's useful, thanks. It was puzzling indeed, because the official number of pages
The page FAQ: C++ Standard has been updated. --Space Mission (talk) 10:19, 22 September 2023 (PDT)

Creating pages

Is it okay for users to create pages on their own? Studyingegret (talk) 02:12, 16 July 2024 (PDT)

It certainly is, rest assured we have some folk here that will edit the page to bring the house style (i.e. "fmt" the page). It's happened many times for users to create pages within their user namespace before moving them over to the main site contents, should you find that preferable. --Ybab321 (talk) 02:17, 16 July 2024 (PDT)
So how do I create a page? How to do it inside my user namespace? Studyingegret (talk) 02:51, 16 July 2024 (PDT)
You just go to the URL that you want your page to live at, let's say https://en.cppreference.com/w/User:Studyingegret/Format, and you'll be given the option to "edit this page" or click "Create" in the top-right --Ybab321 (talk) 05:38, 16 July 2024 (PDT)
I got it, thanks. Studyingegret (talk) 17:46, 16 July 2024 (PDT)

Guide-like stuff

What do you think about writing "guide-like stuff"? What I mean is text that directly tells you to "just do/use it this way" like tutorials, instead of just neutrally listing things like a reference. For example the "Common usage" section on my page.

I don't see this question covered on Manual of style, and I feel that many pages avoid such "guide-like stuff" as much as possible, only writing it to mention something very subtle. So when I think of adding such stuff on such pages, I overthink that the "guide-like stuff" doesn't fit in. But I think "guide-like stuff" is useful for explaining unintuitive things, and some documentations have lots of them, e.g. Python argparse (suggests reading the tutorial) and Rust std::collections.

So to what extent is "guide-like stuff" accepted? Studyingegret (talk) 00:12, 29 July 2024 (PDT)

Retrieved from "https://en.cppreference.com/mwiki/index.php?title=Cppreference_talk:FAQ&oldid=173940"