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,, 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 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: (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 InputIterator
BinaryPred - must meet the requirements of BinaryPredicate

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

Template parameters:

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: 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!)) 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! -- 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 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. 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)
Is it fine ? --Sysroad 17:49, 19 February 2013 (PST)
  • These pages are created. --Sysroad 21:45, 19 February 2013 (PST)
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* 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 is going with tabs, so we can see how that works out: --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
  • how should version differences in the text be displayed?
  • pages that describe multiple version-specific items
(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. (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
  • summaries with multiple versions
(begin and cbegin, but cbegin is C++11 only)
  • version-specific summaries
(C++11 only)
  • version-specific sections of summaries
(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: contains the link:
...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
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)