Talk:Main Page/Archive 1

Archive 1

Archive 2 →

Do you think that another category dedicated to utilities and libraries could be included here?

something like tutorials/examples for make, autoconf, where to find libraries, etc. Just so that the user can obtain all the resources in a single place.

Alexhairyman 07:47, 24 April 2012 (PDT)

I don't think that these subjects would fit into this wiki. We specialize in C and C++ and the wiki is structured specifically for these languages. -- P12 08:22, 24 April 2012 (PDT)

Not even a development process/miscellaneous page? Something for coding standards/style, that may be too opinionated for a site with reference in its' name but I feel it would benefit many, I know an integral part of my learning c/c++ was the various tools available to me. Or some basic data on the windows.h and the posix standard documentation, at least where you can find out more information. Alexhairyman 14:04, 24 April 2012 (PDT)

Style wouldn't be opinitionated if it was backed by reliable references.. but what would they be? Besides a few books (Sutter/Alexandrescu, Sutter alone, Meyers, Lakos), there's not much else - you're left with slides from ACCU conferences (where available), Dr. Dobbs, C++ Source, and other online magazines, Sutter's GOTW, which are all opinionated to varying degrees. working through all those primary sources would be like writing your own book. Now the documentation idea could be useful, I think: there already are occasional links to POSIX and MSDN in some of the existing pages here. We could use a small dedicated page listing available online C++ references (IBM, Comeau, Apache, MSDN, cplusplus.com, STL) and related standards (POSIX, Unicode). --Cubbi 15:05, 24 April 2012 (PDT)

I've considered such idea before, but haven't implemented it yet. A directory of links to useful resources is a very good thing to have. Maybe it's time to start one? -- P12 15:40, 24 April 2012 (PDT)

I think a 'links to resources' page is a fine idea, as long as we keep the scope limited to the best of the best -- maybe one rule of thumb would be to not let it grow past one screenful. What I think we should avoid is having a dumping ground for everything vaguely related to C or C++, which won't help people looking for good information and will be hard to maintain. --Nate 19:01, 24 April 2012 (PDT)

But I think the problem is where to put it. Do we want to add another category? Or simply link in a page where relevant? (which would kind of suck for end-users) I would be happy to do the research for the linux/posix side. The easiest link to throw down is the documentation to Glibc, although organized a little oddly, it makes finding out how to solve your Unix problem much easier, and is super complete. Links to boost.org would be a must also, apache portable runtime, etc. Rather than a new section, a respective page for each language may work too. I think though, that we should come to a common consensus before anyone makes some major change to the wiki. Btw, Thank you all for being so welcoming to a new member in your community, I've been watching the site for a few months now, and it has really become much more expansive and useful! Alexhairyman 22:26, 26 April 2012 (PDT)

We're always happy to have more people helping out.  :) As far as where to put a single 'links to resources' page, perhaps we could start by putting one at the top level of the C++ site: http://en.cppreference.com/w/cpp/resources (I'm assuming that it would make sense to have C++-specific resources, given the links that e.g. Cubbi proposed above.) Once it seems solid, we could start by linking to it from the FAQ. --Nate 04:04, 27 April 2012 (PDT)

What do you think about cpp/links as the location of that page? Resources seems to imply that we are hosting something, whereas links correctly describes the content of the page - it's just a list of links. It is also a shorter URL by the way. -- P12 13:42, 27 April 2012 (PDT)

"cpp/links" works for me. --Nate 15:55, 27 April 2012 (PDT)

All in favor say aye! I say aye! cpp/links Alexhairyman 09:28, 29 April 2012 (PDT)

I agree that there are valid reasons for having such additional information somewhere. I object to this particular solution of the problem, not the idea itself. May I explain this using an example. Imagine two extreme cases. The first one: there's a single wiki about C, C++, make, autoconf, etc. - everything mixed. The second one: there are a number of different wikis one for a particular subject. Which one would be easier to manage and better for the reader? The first one, believe me, would eventually become a huge mess, because the C/C++ material would slowly mix with other material and vice-versa. Thus I'm advocating for a set of wikis with strictly defined boundaries, each specializing into a particular subject. We specialize in C and C++ reference. I'd be happy if someone created a similar, specialized wiki for make/autoconf (I might even help to set everything up). But I'm against including the same material here. -- P12 15:45, 24 April 2012 (PDT)

Template arguments

Most of the templates in C++ have requirements on their template arguments. Some of these requirements are quite complex. Therefore, I think it's worth to add a separate section outlining these requirements, with links to concepts, if appropriate. I am, however, unsure, in which format the arguments should be described. Here's what I have thought of so far:

---

Option 1: A separate section before the parameters section.

Template parameters

InputIt1, InputIt2	-	must meet the requirements of LegacyInputIterator
BinaryPred	-	must meet the requirements of BinaryPredicate

---

Option 2: Additional explanation after the main description, before the parameters section:

Template parameters:

• InputIt1, InputIt2: must meet the requirements of LegacyInputIterator.
• BinaryPred: must meet the requirements of BinaryPredicate}}

---

In addition to that, I'm unsure what exact terminology should we use: "template parameters", or "template arguments", or "type requirements", or something other. Finally, after adding the longer explanations of type requirements, the names of the types can be shortened, as there won't be any need to convey full explanation just by the name of the identifier. So we probably should agree what consistent names we will use throughout the wiki. Here's the initial list:

• InputIt - input iterator.
• OutputIt - output iterator.
• ForwardIt - forward iterator.
• BidirIt - bidirectional iterator.
• RandomIt - random access iterator.
• Pred - unary predicate.
• BinaryPred - binary predicate.
• Op - operation.
• BinaryOp - binary operation.
• Traits - traits: string traits, regex traits, etc.
• Alloc - allocator.
• CharT - base characer type.
• ...

What do others think about this? -- P12 08:01, 17 May 2012 (PDT)

I'd prefer option 1 as it puts template parameters closer to the function parameters. There are cases where template parameters *are* the inputs, e.g. in the ratio library, the type traits, std::get (and other functions with non-type template parameters), and I kinda feel that they should be treated similarly. And yes, consistent and precise naming for template params would be great. --Cubbi 10:37, 17 May 2012 (PDT)

I like option 1 as well. --Nate 06:05, 18 May 2012 (PDT)

You should call them template parameters. When you declare a template the names in <> are template parameters. When you instantiate a template the names in <> are template arguments -- Ville 02:28, 11 June 2012 (PDT)

Page width

The wiki pages are too wide and thus places important information to the right of a page. Main page, at least with default theme, places the section headers: "C++ reference" and "C reference" to the left of their respective indices, thus pushing the interesting parts to the right and possibly out-of-view. Those section headers should be placed above their respective indices.

Also the wiki related link sections "Navigation", "Toolbox" and "In other languages" aren't at all that interesting when using this site as a reference. However the links on the right hand side on the individual pages like: http://en.cppreference.com/w/cpp/container/array are. Again those are pushed unnecessarily to the right and are again possibly out-of-view. -- Ville 02:43, 11 June 2012 (PDT)

Hi. This problem is known to us. A new layout solving this issue has already been developed and will be deployed in the following days. You can see several examples of the new layout in action: [1] (the main page), [2] (shows the replacement of the right sidebar).

How to write a class that uses a structure as a private datatype and uses it's pointers in the implementation.

class PQueue{ public : /*other public functions and the constructors,destructors*/ private : struct chunkT{ vector<int> nums ; chunkT *next ; }; /*other private functions*/ }

The implementation code uses the struct chunkT to generate a linked lists of the given type but gives many errors .

basically , the error messages reported demonstrate that the compiler did not identify the data type : chunkT

Please suggest a reason for this behaviour or give a sample function to be written in the implementation that uses a pointer to the struct chunkT .

many thanks in advance . :)

--Nikunj 07:46, 16 July 2012 (PDT)

This is a discussion page dedicated to the improvement of this wiki. This is not a forum. Besides, you've already asked your question at one --Cubbi 09:01, 16 July 2012 (PDT)

Pages accessible through built-in Search

Hello everyone -- I'm new to cppreference, just found it and I'm quite interested.

I have a question regarding the built-in search function: it seems to exclude keywords and pages that do not refer exactly to a member of a library. Is it what is wanted? Jocelyn 07:15, 20 July 2012 (PDT)

Yes, our custom search engine isn't sophisticated enough to provide sensible results for arbitrary queries. You can use an external search engine such as Google if the results are inadequate. -- P12 14:07, 20 July 2012 (PDT)

Just to elaborate a bit -- we use a custom search because the built-in plaintext search generates a lot of noise with our specific content. We have been working on improving the custom search, however, so hopefully it will continue to improve. In the meantime, the search results include links to external engines that might get closer to what you expected. --Nate 14:49, 20 July 2012 (PDT)

Suggested page(s)/table(s) - "Since C++11" summary and "C++11 via Boost" summary

I think it would be a good idea to have a page with a table (or separate tables) that lists all of the "since C++11" elements as well as those that came to "C++11 via Boost" elements. The table entries would be click-able links to the language elements themselves.

I am just gauging interest so I'll leave formatting ideas out of this for now as well my reasoning for having such a table. --Arbalest 10:29, 5 October 2012 (PDT)

"C++11 via Boost" describes the history (for which we have cpp/language/history), but I don't think it's particularly helpful as part of a reference. Quite a few bits and pieces changed as the libraries moved from boost to TR1 and from TR1 to C++11, and then boost keeps improving and expanding its libraries, while C++11 is fixed, for now. We could have a special "See also" category just like we have a "See C reference" for boost-originated components, something like "See also: xxxxx in Boost". --Cubbi 10:40, 5 October 2012 (PDT)

I think third-party libraries should not be linked from the reference itself, because this would result in a mess in the long term. There are many libraries that perform similar tasks as the standard libraries. Moreover, boost is not the only one that has an API very similar to one of the standard libraries. It would be hard to establish a criteria that defines which libraries can be linked to and which not. Therefore I believe this isn't a good idea. A better place place for such links would be cpp/links/libs. -- P12 09:49, 20 October 2012 (PDT)

In my opinion having a list of all changes between standard revisions is worthwhile. Maybe not in cpp/language/history, but cpp/changelog for example. -- P12 09:53, 20 October 2012 (PDT)

More visible search box

The search box is really useful and in most cases, the users wants to find a function (printf, scanf, pow, … for instance) and as now, it's quite hidden.

(BTW, very nice, very well organized, a big thanks to the creators (yes, you!))

93.20.177.195 16:21, 14 November 2012 (PST)

Thanks for the comment. Do you have any suggestions on how the search box might be made less hidden? I think keeping it in its current location is good, as it's fairly standard for websites to have search in the top-right. One option might be giving the background of the box a light shade of color, or gray. Another option might be outlining the box in darker color. -Nate 08:23, 15 November 2012 (PST)

As casual user of this site I think the search box could have more width, and maybe a bit more height.

But it would be much more useful if you could selectivly only search the page titles, or the page contents.

Anyway: great work you're doing! --87.148.222.140 13:31, 12 January 2013 (PST)

no vandalism?

Why does this wiki not suffer from vandalism, or only little?? I just did some minor fixes, and it appears that the page contents are only protected by some easy "cpp captcha". Honestly, everyone who skimmed through en.wikipedia.org/wiki/C++ can know what the output of cout <<... is. I'm used to wikipedia, and I'm missing (I don't really miss it) the trolls who happily post ads, or garbage information... if that happens in future, one should consider a more complex security question. 87.148.222.140 13:46, 12 January 2013 (PST)

Sure, that's in our plans. Hopefully we won't need to enact harsher measures, as they don't help the contributors :) P12 16:26, 12 January 2013 (PST)

C++ keywords search with search box

Tried to search some C++ keywords (constexpr, typename) and it doesn't work with built-in search, but searching for STL stuff works OK. Thanks for this awesome site, btw.

The search currently only indexes methods and classes. Adding keyword support to search results is in the works, though. Until that happens, you can always use the links to external search engine results or just use an external search engine directly. --Nate 07:20, 9 June 2013 (PDT)

more lang support possible ?

Need translation for korean... is it possible ?

The protocol that we've been using to add translations goes something like this: if a user translates the main page, /c, /cpp, /c/language and /cpp/language as sub-pages off of their user page, then we'll look into using that content (along with machine-translations) to start a new translation of the site. --Nate 07:27, 15 February 2013 (PST)

• Create Main Page of [ko:] like this. http://en.cppreference.com/w/ko:Main_Page

Is it fine ? --Sysroad 17:49, 19 February 2013 (PST)

• How do I change the URL http://en.cppreference.com/w/ko:Main_Page to http://ko.cppreference.com/w/Main_Page ? --Kkspoint 21:09, 19 February 2013 (PST)

• These pages are created. --Sysroad 21:45, 19 February 2013 (PST)

http://en.cppreference.com/w/ko:Main_Page

http://en.cppreference.com/w/ko:/cpp

http://en.cppreference.com/w/ko:/cpp/language

http://en.cppreference.com/w/ko:/c

http://en.cppreference.com/w/ko:/c/language

It's looking like it's coming along nicely. Once the c/language and cpp/language pages are completed, we'll do the server-side updates that will create the actual ko.cppreference.com/* pages. --Nate 06:48, 20 February 2013 (PST)

As the required pages have been translated, I've initialized a Korean wiki at [3]. Good luck! P12 07:43, 2 July 2013 (PDT)

Viewing multiple versions

I think that the approach on this page to presenting historical information is a bit awkward, and is only going to get worse as future standards are released. I'm worried that the historical revision boxes add a lot of clutter and will increasingly not be what most people are looking for. I propose that for inline text like this, we describe behavior according to the current standard, and use the revboxen for historical information. Any thoughts or objections? --Nate 07:34, 2 January 2013 (PST)

In a few months we'll have a draft C++14, so yes, this will get harder. Maybe there's another way? How about a page that shows everything as current, with a clickable tag that unhides the changes from older revisions? Or even tabs that redraw the page completely? --Cubbi 08:31, 2 January 2013 (PST)

How does this sound as a first step: show current content by default, have historical changes in revbox lists, but have the revbox lists be hidden by default behind clickable "show changes" tags? --Nate 09:42, 2 January 2013 (PST)

This is good idea in principle, I like it. Here are some thoughts:

• Client-side implementation using Javascript is the best option, I think. Server-side implementation would be slower and hard to implement.
• If an user selects a non-default standard version, we probably want to remember his choice. Will need cookies to implement.
• It's probably worthwhile to allow direct linking to a standard versions via additional URLs parameter.
• This would be quite major change. It may be non-trivial to sync this with the translations. We need to keep this in mind.
• Interactive features may not play nice with offline viewers.

P12 13:53, 4 January 2013 (PST)

These are all good ideas, and I think it's true that they could require some work to fully implement. It seems like a relatively easy first step would be to write the main content for the current standard and include historical notes in revboxes. Then, as we have time, we can figure out how to implement appropriate client-side functionality to show/hide the historical notes. Any objections? --Nate 08:39, 6 January 2013 (PST)

Hmm, but wouldn't it become ambiguous which version of the standard specifies what? At least now we can precisely say that, e.g. x = 1 in C++11, but x = 0 in the previous versions.

In my opinion it's worth to divide the problem into two parts: how we use revboxes at source level and how they appear to the reader. I'd like to put all changes between standard revisions into revboxes at the wikitext level, because then we have much larger freedom specifying which information we show.

As for appearance, my vision is that we either show the information about one standard (and explicitly note which one somewhere in a visible location). Or we show all the changes between standards in an ugly, but unambiguous table. If single wikitext definition is used, then implementing switching between these two views wouldn't be hard.

What do you think?

That could definitely work. My main concern is that whatever version we end up showing by default to non-logged-in users should be easy to parse (i.e. not riddled with diffs or awkward formatting due to a bunch of hidden revboxen), but I think that's achievable as long as we're careful about where we insert revboxen.

To achieve this, we'd need to (a) elaborate the revlist template a bit and (b) add some client-side UI/state that could control the display of whatever the revlist template spits out. Anything else? Off the top of my head, one way to do the UI would be a dropdown similar to the "actions" menu with e.g. C++98, C++03, C++11 in it. --Nate 08:12, 11 January 2013 (PST)

My opinion is almost exactly the same on all points. We don't need much more than a bit of Javascript. As for drop-down menu, it would be quite hard to add it next to the actions menu, because that part of the UI is controlled by the skin file. A possible way around this could be to add the menu below the actions button instead of next to it. The menu could look like the current navbar and possibly integrate with it.

One additional thing that we need to discuss is how we should present the descriptions of classes and lists of functions in the global namespace. For example, should we hide/show the member functions depending on the selected standard?

P12 16:09, 12 January 2013 (PST)

Assuming you meant e.g. "should cpp/container/vector display a listing for emplace_back when C++98 is selected", that's an excellent question. In addition, if we have a numbered list of overloads (e.g. at the top of cpp/container/vector/insert) then hiding some of them will mean renumbering subsequent references. Also, we should consider the case when the user is viewing e.g. cpp/container/vector/emplace_back -- what should happen if they try to switch to C++98?

We have lots of content that is currently version-labeled. It's entirely possible that we could actually make the site more confusing if we introduce a C++11/C++98/C++03 dropdown that isn't consistent/complete about what it displays. --Nate 12:46, 13 January 2013 (PST)

If we implement the standard menu in a similar way as navbar, option to switch to C++98 could be hidden. As for renumbering, I don't have any ideas of a maintainable way to implement it short of removing the numbering. This could be a real problem. P12 07:26, 14 January 2013 (PST)

Let's think about it and see if we can come up with a sensible way to deal with revisions. I'd like to make pages like this a little easier to parse, but we have time to figure out how to do it right. --Nate 17:14, 15 January 2013 (PST)

I think a good option would be having different CSS styles available which can be selected in the user preferences

Some styles that may be useful:

• show C++11 without special formatting, C++03 as a collapsible box (and vice-versa)
• visually mark all the alternatives
• show just C++11 or just C++03

(As C++11 is not fully implemented someone may be interested in the C++03 reference and only that)

--Bazzy 09:52, 2 January 2013 (PST)

(UPD: looks like cplusplus.com is going with tabs, so we can see how that works out: http://cplusplus.com/reference/string/string/data/ --Cubbi 13:24, 29 January 2013 (PST))

That's interesting. I don't really like the "one tab per diff" approach that they use; I feel like if I want to see e.g. C++11 content, I want to see it consistently throughout the current page. Having separately-clickable tabs makes it easier to explore the differences, but I'm still skeptical about how many people really want to examine diffs, versus how many will just want the most recent content. :) --Nate 17:26, 29 January 2013 (PST)

I have pretty much the same opinion. I wonder how they'll implement versioning of member function listings (if they do this at all).

By the way, we can also look at their implementation of declaration block versioning (example with several declarations). Quite unclear I'd say. Since there's no per-overload description, one needs look at the parameters section to understand what exactly each overload does. P12 20:37, 29 January 2013 (PST)

Multiple versions brainstorming

Summarizing the above section:

1. multiple versions are probably worth displaying, but clutter is bad
2. storing all of the revision information in a canonical format (like revboxen) will allow it to be displayed in a variety of ways
3. client-side javascript (possibly with cookies) could drive the website UI

Here is a (partial) list of page/template types that our solution should consider:

• pages with version-specific information

e.g. http://en.cppreference.com/w/cpp/string/basic_string/data

• how should version differences in the text be displayed?

• pages that describe multiple version-specific items

e.g. http://en.cppreference.com/w/cpp/string/basic_string/begin

(contains both begin and cbegin, but cbegin is C++11 only)

• if we selectively display items from the syntax list, how should numbering work?

• pages that describe items that only appear in a single version

e.g. http://en.cppreference.com/w/cpp/string/basic_string/front (C++11 only)

• should there be an option to view C++98 content on a C++11-only page?

• pages that display lists of links

e.g. http://en.cppreference.com/w/cpp/string/basic_string

• summaries with multiple versions

e.g. http://en.cppreference.com/w/Template:cpp/string/basic_string/dcl_list_begin

(begin and cbegin, but cbegin is C++11 only)

• version-specific summaries

e.g. http://en.cppreference.com/w/Template:cpp/string/basic_string/dcl_list_front

(C++11 only)

• version-specific sections of summaries

e.g. http://en.cppreference.com/w/cpp/string/basic_string

(non-member "numeric conversions" section is all C++11)

• should the entire section be selectively displayed?

• all pages

• sections like "Exceptions", "See also": if they only contain version-specific information, should the entire section be displayed for other versions?
• version-specific links:

http://en.cppreference.com/w/cpp/language/static_assert contains the link:

http://en.cppreference.com/w/cpp/types#Type_traits_.28since_C.2B.2B11.29

...which jumps to a version-specific location on the type_traits page

This is a lot of stuff to consider, so I'd imagine that our ideal solution will be something that we can implement incrementally. For example:

1. modify revbox/dcllist/etc. templates to allow explicit version tagging, but have templates continue to display current output
2. change existing version-specific content to use the new templates (some of this could possibly be done by robot)
3. implement javascript UI to allow version selection

--Nate 19:01, 2 February 2013 (PST)

I think that versioning could be implemented entirely in javascript without any new support from MediaWiki templates. Javascript isn't limited language like they are, so matching of much more complex patters could be implemented. This means that the necessary information is already included via {{mark since/until **}} templates, so the wikicode doesn't need to be changed (well, except an occasional new html class attribute). Therefore, we don't need to spend much time syncing with translations and there won't be any new compatibility issues to solve. It's win-win. P12 04:19, 27 February 2013 (PST)

That's a good idea. I assumed that the variety of cases that we'd want to cover would prevent a js-only approach, but that might not be the case. I'll look at the various cases and see if we can do this without new templates. -Nate 12:42, 27 February 2013 (PST)

After looking at some examples, I think that we can do a lot of the versioning in javascript, but there are a few places that will warrant template changes. The best examples I've found so far are the use of <br> tags as "fake" table rows. For example, the links to begin and cbegin in Template:cpp/string/basic_string/navbar_content produce HTML with multiple nested parallel table cells, each with <br> delimited content. Writing rules to match content in these cells to eachother while ensuring that no stray newlines were left behind would be difficult and would produce a fairly brittle solution. And it would only get worse when we try to add additional versions.

I think we would have a much more robust system if we replaced e.g. the "fake <br> multiline" begin/cbegin entries with two separate entries. Both entries could still point to the same page. -Nate 17:12, 4 March 2013 (PST)

<br> are used in dcl list templates too. Replacing the newlines with divs or tables would need not only these templates to be changed but also all inclusions where one entry describes several members. <br> is also used in ddcl list templates where one entry describes two different versions of the same function.

The above means that a lot of work would need to be done to adapt the templates and the wikicode would become quite complex. Also in the cases of navbar and dcl list, we would lose the visual feedback that the items within an entry all lead to the same page.

I think that JavaScript should handle all these cases just fine. The script could interpret the <br> tag as a delimiter when traversing the DOM tree. It shouldn't be very hard to implement the script to handle

<td>A<br/>B</td> <td>C<br/>D</td>

as if it was

<td><div>A</div><div>B</div></td> <td><div>C</div><div>D</div></td>

A more problematic case is with ddcl list since we have several corner cases. These could be handled by creating a special template that is more complex but exposes more information in HTML.

P12 11:08, 5 March 2013 (PST)

So one of the problems with <br>s is that (as far as I know) text children in the DOM ("A" and "B" in your example) can't be manipulated in the same way as element children ("<br/>" in your example) -- specifically, their visibility can't be changed. To deal with this, I think we'd need something like a pre-processing step that actually modifies the DOM, replacing text children (e.g. "A") with wrapped element children (e.g. "<span>A</span>").

Having to add markup after the fact with javascript seems like a reasonable sign that the wiki is missing some key information. In this case, we're using <br>s -- which are normally used for presentation -- to separate semantically different items.

I don't think that we need to get rid of all of the newline formatting, at least not initially. It's currently only a problem for things like begin/cbegin, where the two items have different semantics. Most of the entries in Template:cpp/string/basic_string/navbar_content that use newlines have the same semantics (e.g. stoi/stol/stoll) so they could remain unchanged.

One thing that I'm a little confused by is how such a change could make the wikicode more complex. I can see it making it longer, since we'll e.g. replace a single begin/cbegin item with two items, but that doesn't seem too horrible. Am I missing something? -Nate 15:52, 6 March 2013 (PST)

The complexity is with dcl and ddcl list templates. Navbar is pretty much safe to change.

I agree with your statement that the wiki misses some information that is indeed necessary. I've concluded that my previous suggestion is quite wrong in multiple ways.

I think that we can do the same with some clever use of templates. Essentially we want a<br/>b to be changed to <span>a</span><span>b</span> (divs don't work within links, spans can be display:block via css). The solution could be similar to <span>{{#replace:{{{1|}}}|<br/>|<span/><span>}}</span>. Even better thing would be to introduce some kind of dedicated separator, say '@' or '%%' characters. This could even increase the readability of templates. P12 18:46, 6 March 2013 (PST)

Proposed changes and additions

Fixing this issue is going to be a major change. The list below includes a lot of unrelated changes that could go along. So here it goes:

1) Rename {{rev list begin}}, {{rev list item}} and {{rev list item}} to {{rev begin}}, {{rev end}} and {{rev|since=std-rev|until=std-rev}}. std-rev default to the first and the latest standards respectively. The behavior would be the same as before. Each of the {{rev std-name}} could carry a style attribute that would make hiding items much easier.

2) Rename {{dcl list ***}} templates and all the accompanying templates to {{desc ***}}.

3) Delete {{ddcl}} template. Use a combination of {{ddcl list begin}}, {{ddcl list item}}, {{ddcl list end}}.

4) Rename {{ddcl list ***}} templates to {{dcl ***}}. Rename {{ddcl list item}} to {{dcl|since=std-rev|until=std-rev}}. std-rev default to the first and the latest standards respectively. Add {{cpp/std rev}} that would return the revision of the standard the specific feature is defined in the first time (this could be used to retrieve std-rev in templates). Add a set of templates for displaying changes between revisions, so e.g. the declarations here could be implemented as:

{{dcl begin}}
{{cpp/container/if ord | {{{1|}}} |
{{dcl rev begin | num=1}}
{{dcl | until=c++11 |
void erase( iterator pos );
}}
{{dcl | since=c++11 |
iterator erase( const_iterator pos );
}}
{{dcl rev end}}
{{dcl rev begin | num=2 }}
{{dcl | until=c++11 |
void erase( iterator first, iterator last );
}}
{{dcl | since=c++11 |
iterator erase( const_iterator first, const_iterator last );
}}
{{dcl rev end}}
{{dcl | num=3 |
size_type erase( const key_type& key );
}}
|
{{dcl | num=1 | since={{cpp/std|{{{1|}}}}} |
iterator erase( const_iterator pos );
}}
{{dcl | num=2 | since={{cpp/std|{{{1|}}}}} |
iterator erase( const_iterator first, const_iterator last );
}}
{{dcl | num=3 | since={{cpp/std|{{{1|}}}}} |
size_type erase( const key_type& key );
}}
}}
{{dcl end}}

5) Rename {{param list ***}} to {{param ***}} except for {{param list item}} which becomes just {{param}}.

6) Rename {{sparam list ***}} to {{sparam ***}} except for {{sparam list item}} which becomes just {{sparam}}.

7) Rename {{sb list ***}} to {{sb ***}} except for {{nv list item}} which becomes just {{nv}}.

8) Add a new list syntax that would indicate that the numbers in the list need to be renumbered by Javascript when the set of visible overloads changes. We can use this syntax for example: $number$. All references to the overloads within text will need to use the same syntax in order to be appropriately renumbered.

9) Use $$ within {{desc ***}} and {{nv ***}} to separate {{mark std-rev}} templates. The templates themselves will search/replace $$ with a proper HTML construct that CSS can be applied on selectively.

10) Javascript hides empty See also sections that just had their contents removed.

11) Use {{rev ***}} templates in the Exceptions section in places where we use lone {{noexcept}} template now.

12) Distribute separate offline documentation for each standard. This would allow us to pre-process the documentation and not require JavaScript for satisfactory experience when viewing the archives offline.

Most of the renames of templates need not to be done at once. The transition could be incremental. P12 17:23, 23 May 2013 (PDT)

I like it, and I'm willing to do some grinding to convert over. However, I'm not sure exactly how much work it will be to do this, mostly because I'm unsure how much can be achieved by robots. Care to comment on what parts will have to be done manually vs. automatically? --Nate 16:13, 24 May 2013 (PDT)

Only very complex cases will need human intervention. The rest can be done automatically. P12 08:30, 27 May 2013 (PDT)

Updates: I think it's worth to reduce verbosity and use dsc instead of desc, par instead of param, spar instead of sparam. P12 10:47, 31 May 2013 (PDT)

Points (1-3) and (5-7) have been done. Point (4) have been almost done too, only updating the current pages to use new syntax is left. P12 19:57, 4 June 2013 (PDT)

Everything except points (10) and (12) have been completed.

Highlighting inline code snippets

We have a lot of places where text is mixed with lots of snippets code snippets. This leads to loss of readability, since it's hard to tell where a snippet begins and ends. I propose to use a different background color to highlight such snippets. This would apply to all snippets that use the {{c}} template. Compare:

No highlighting

1) If bool(lhs) != bool(rhs), returns false

Otherwise, if bool(lhs) == bool(rhs) == false, returns true

Otherwise, returns *lhs == *rhs.

2) If bool(rhs) == false returns false

Otherwise, if lhs == false, returns true

Otherwise returns std::less<T>{}(*x, *y)

3) Returns !opt.

4) Returns false.

5) Returns !opt.

6) Returns bool(opt)

7-8) Returns bool(opt) ? *opt == value : false.

9) Returns bool(opt) ? std::less<T>{}(*opt, value) : true.

With highlighting

1) If bool(lhs) != bool(rhs), returns false

Otherwise, if bool(lhs) == bool(rhs) == false, returns true

Otherwise, returns *lhs == *rhs.

2) If bool(rhs) == false returns false

Otherwise, if lhs == false, returns true

Otherwise returns std::less<T>{}(*x, *y)

3) Returns !opt.

4) Returns false.

5) Returns !opt.

6) Returns bool(opt)

7-8) Returns bool(opt) ? *opt == value : false.

9) Returns bool(opt) ? std::less<T>{}(*opt, value) : true.

P12 10:47, 18 May 2013 (PDT)

A little highlighting seems like it could be improvement, at least in the cases that you posted. Will it work as well across all the locations the the "c" template is currently used? For example, inside the various tables on ios_base or on top of the already-darkened background boxes on basic_stringstream? --Nate 12:58, 19 May 2013 (PDT)

I think it should apply everywhere. My reasoning is that by using {{c}} instead of {{tt}}, one asks for highlighting anyway, thus additional background shouldn't make matters worse. The background should be applied to code in darkened boxes too (this will be a bit harder to do properly, but possible -- e.g. using something like semi-transparent black color).

The only problem that I see is that the {{c}} template is currently used to make links, e.g. std::string within text. The issue could be solved by adding a new template for such snippets which would not be highlighted.

The above idea of a new template could be taken even further by developing a specialized extension for link processing. A specialized implementation could work-around the current limitations of Geshi. For instance, automatic linking to related member functions could be implemented -- so, e.g. wikitext {{lc|cbegin()}} in cpp/container/vector/front would automatically link to cpp/container/vector/begin. Such extension would be faster than Geshi too, thus it's a win-win scenario.

P12 15:39, 19 May 2013 (PDT)

Okay, I think that could work. I do like the idea of a specialized extension for link processing. My only concern is an aesthetic one; I like the idea of our "minimal" look, and I think we should keep an eye on pages like those I mentioned above to make sure they don't get too visually cluttered. But as you pointed out we can iterate a bit to make sure that we get it right. --Nate 07:32, 20 May 2013 (PDT)

Diff with last translation ?

Hi, For update translations, it's hard to know if a page is updated with current english version. Is it possible to create tools/macro/template/other to list pages that need a update ?

For example, add

cpp/language

Original:

2013-05-26

The text has been machine-translated via Google Translate.
You can help to correct and verify the translation. Click here for instructions.

in translated page and a special page that lists all translated page where english version was modified since last translation (ie date in template are older than last update in english page)

Thanks, Guillaume Belz 11:10, 26 May 2013 (PDT)

I'll see what can be done. There's possibility that this won't be implemented soon though, since there's a lot of other things in the pipeline. For now, you can translate the current text without checking whether it's out of date or not -- it will be possible to say which translations need to be updated again. The more translations are verified, the higher priority your request will get. P12 07:56, 27 May 2013 (PDT)

Thanks for response

So I am going go to work :)

Guillaume Belz 08:21, 28 May 2013 (PDT)

(HS : how to create its user page ?)

We've disabled editing the user namespace for new users because we get a lot of spam there. Just score ten edits and you'll be able to edit your user page. P12 11:25, 28 May 2013 (PDT)

I've come into conclusion that your idea of using a separate tag to track the date of synchronization is the best idea. I've created a template {{trd}} for this purpose. It will output an invisible tag that could be used to create a list of pages that need updates. P12 21:35, 7 June 2013 (PDT)

News section in the main page

I think it's worth adding a news section to the end of the main page and list any changes that might be interesting to a lot of people (e.g. new offline package version, support of a new standard, large layout changes, etc.). P12 13:09, 28 May 2013 (PDT)

That could be useful. I think the main page should still be focused on the C++ and C top-level sections, but we can probably find a non-emphatic style for a news section. (Actually, just having such a section below the other two will go a long way in this regard.) One idea is an indented third box below the "C" box with a smaller header. --Nate 17:34, 28 May 2013 (PDT)

Using https?

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

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

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

{{langlinks}}

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

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

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

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

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

noexcept in declarations

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

This is a fair point. I think the original idea might have been an interest in avoiding a situation where we show too many technical details up front, possibly interfering with the presentation of more important information. Do we have any ideas about how much text would be added to declarations (i.e. would it just be appending the word "noexcept" in a few places, would it involve massive noexcept blocks all over the place, something in between, etc. :) --Nate (talk) 11:56, 23 August 2016 (PDT)

I wouldn't put massive blocks up top, cpp/utility/variant/swap can say noexcept(/*see below*/) up top and keep the existing noxcept block where it is, under Exceptions. --Cubbi (talk) 13:08, 23 August 2016 (PDT)

That seems pretty reasonable. --Nate (talk) 11:41, 24 August 2016 (PDT)

+1. I never quite understood why noexcept isn't in the declaration. T. Canens (talk) 15:13, 30 August 2016 (PDT)

I'll start rolling {{noexcept}} into the function declaration since there appears to be no objections. T. Canens (talk) 13:30, 10 March 2017 (PST)

http://en.cppreference.com/w/cpp/named_req/AssociativeContainer

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

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

How should copyright be added to code examples?

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

Question open to License X for future referencing.

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

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

I'd like to hear what others think. Mixing licenses is a headache (cppreference is dual-licensed under CC-BY-SA and GFDL) and I'd rather avoid it if at all possible, although Boost is permissive enough that I don't think compatibility is a problem. But if we have to do something like this, I suppose we can put a link to a license page somewhere, e.g., something like Second version^{[Boost licensed]}, roughly approximating the behavior of Wikipedia's image copyright tags. T. Canens (talk) 01:31, 29 January 2017 (PST)

Agree on all points. If at all possible, avoid putting copyrighted code here. It's completely fine to leave e.g. the possible implementations section blank for now if you can't fill it out -- perhaps someone else in the future will be in a better position to do that work. --Nate (talk) 08:20, 30 January 2017 (PST)

Can I has rollback?

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

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

Ferror prints errors associated to this particular stream.

Perror prints errno.

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

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

Indeed, perhaps it was added just because it sounds similar? (like the two std::move or the two std::rename pages link to each other). In any case, I dropped it from the seealso in c/io/ferror. --Cubbi (talk) 06:00, 17 February 2017 (PST)

No, you didn’t c/io/ferror#See_also ;/ You dropped in from cpp/io/c/ferror, not from c/io/ferror

okay, done there too now.. This is a public wiki, you could help editing, too! --Cubbi (talk) 04:43, 18 February 2017 (PST)

noexcept on swap

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

Sure, just use std::iter_swap instead. --84.63.27.42 05:38, 4 June 2018 (PDT)

New MathJax gadget

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

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

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

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

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

is confusing to some users. How about this format?

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

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

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

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

description (function template)

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

"added in"? I'm not that convinced that there's a problem. Like C++ we use half-open ranges. T. Canens (talk) 11:53, 11 July 2017 (PDT)

All right, looks like a decent number of people do hate "until". But the problem is that we currently use "until" for both changes and outright removals. "removed" works well for the second but not for the first.

Regardless, I think we should edit {{dcl}} to have "deprecated" as a first-class option, then audit all {{mark|deprecated in C++XX}} usages so that we can present the standard revisions in chronological order. T. Canens (talk) 13:04, 11 July 2017 (PDT)

chronological order is definitely a good step --Cubbi (talk) 13:22, 11 July 2017 (PDT)

OK, here's what I've implemented so far:

• {{mark until c++XY}} has gained an optional removed parameter; removed=yes causes it to render as (removed in C++11) rather than (until C++11).
• {{dcl}} has gained two parameters, deprecated and removed.
  • deprecated is straightforward: it adds a "deprecated" marker after the "since" marker and before the "until" marker. deprecated=yes adds (deprecated); deprecated=c++XY adds (deprecated in C++XY).
  • removed selects the version of the "until" marker to use. It can be yes or no. If not specified, defaults to no if deprecated is not present and yes otherwise.
    • If until is not specified, then removed=X is a shorthand for until=X|removed=yes.

T. Canens (talk) 14:16, 14 July 2017 (PDT)

Delete unused zh-version of pages

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

zh:User_talk:T._Canens#Deleting zh-version of some pages

I guess that they will never be used again.

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

All zapped. I don't visit zh regularly, so in the future please ping my en talk page. T. Canens (talk) 14:05, 27 November 2017 (PST)

What you think of this example?

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

I would describe that as practical examples vs. unit-tests as examples. The description already said what remove_cvref does. The example illustrates how that description applies to several concrete cases, and that is useful for understanding the description. I sometimes edit such examples down to limit them to substantially distinct cases (there for example, remove_cvref_t<int&> doesn't add anything substantial to remove_cvref_t<int&&>). It's true that practical uses in examples bring value not already found in the description (e.g. my cpp/io/ios_base/register_callback#Example brings additional value to that page over simply calling register_callback and asserting that it was called, even though that example is larger than we'd like). If you have a concise, practical demo of remove_cvref as it would appear in code, by all means, edit it in. You could still leave a few lines of asserts in the same example to show how the description applies to a few specific types. --Cubbi (talk) 10:22, 20 December 2017 (PST)

Thanks. I agree with you that lots of what cannot be well described in words can be vividly shown by an example, which is "technical", like the asserts mentioned. Such examples meet users' demand of more details about the documented feature. They are completing the describing words. Users do also need practical examples. Practical examples and unit-tests shall be both placed, whose style of the page, however, will be like what? It does not seem right to simply place one after another in the section Example, for which gives readers a misconception that they are two similar examples that become strange to be merged together. I also thought of placing the "technical" one in the description section and as a part of the words describing the feature (how to organize?) and the practical one, as usual, in the section Example — by this way, the (originally) "technical" one became description in another way and the practical one integrates the feature into practice and shows ways it is used. More ideas? --LittleFlower (talk) 02:35, 21 December 2017 (PST)

It is indeed "description in another way". There are existing situations where such (unit-test style) examples are actually placed in the descriptions: this is common under cpp/language. For example, cpp/language/new has many micro-examples interspersed in the description. Under library references, the descriptions are typically short and followed by Parameters, Return, and Notes, and there is also some value in keeping all that visible at a glance: I've seen questions on stackoverflow that link to a cppreference page that could have been answered just by reading the Notes on that same page. Why is it strange to have different things shown in an Example though? cpp/algorithm/rotate#Example shows both a simple rotation to the left (effectively a unit test) and a simple rotation to the right (a popular trick) and an insertion sort (a practical use). Just comment before each part to say what it is for. --Cubbi (talk) 04:16, 21 December 2017 (PST)

Sorry! Apologize for I didn't think carefully before I leap. I did not check it carefully. --LittleFlower (talk) 22:59, 22 December 2017 (PST)

Wrong format

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

not really, I saw all letters bold Yaossg (talk) 21:18, 1 January 2018 (PST)

Also, that bolding is done by MediaWiki directly. Even if it were somehow bugged, that's not something we can fix. T. Canens (talk) 12:49, 10 January 2018 (PST)

OK. I see. It is indeed left not bold on my browser (I checked it). Maybe it is my device bug.--LittleFlower (talk) 02:57, 11 January 2018 (PST)

Do you really mean this?

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

Not sure.but in fact, you ought to create talk page on its own place instead of here Yaossg (talk) 02:48, 19 January 2018 (PST)

Fixed. But yes, in the future please use the talk page of the page concerned (or just fix it yourself). T. Canens (talk) 13:16, 19 January 2018 (PST)

containers on main page

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

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

Option for showing only a specific standard version

With the various standards some pages got quite confusing with all the until/since clauses (see e.g. std::basic_string::basic_string). Would it be possible to change wiki-templates such that something like buttons allow for showing content only for a chosen standard (like c++17 or c++20)? --Bear (talk) 03:46, 3 March 2020 (PST)

You can enable <gadget-StandardRevisions> in Special:Preferences#mw-prefsection-gadgets. There's also a browser extension created by User:ISSOtm. --D41D8CD98F (talk) 02:25, 4 March 2020 (PST)

Wow great, thanks. --Bear (talk) 06:43, 4 March 2020 (PST)