Namespaces
Variants
Views
Actions

Talk:Main Page

From cppreference.com
Replacement filing cabinet.svg

Archives

Archive 1 Archive 2

Contents

[edit] Alphabetical Index

I think that this reference needs an alphabetically ordered index pages. I would create them but I am not sure if the site maintainers will accept them. If you create an index I would work on it.

[edit] Qt help book

It does not have the same front page as the online reference. There is no link to the C reference. It would be nice that the C reference is linked somewhere too. The FAQ link is also broken.

[edit] Anki Deck Export

I would like to propose a new export type to support Learning C/C++, STL, and C++ version differences. That type is for Anki (https://ankiweb.net/) a cross platform flashcard system.

Rationale: I have been trying to catch up on my C++ vs C++11 and brush up on my C++/STL in general using Anki, and an OOP concepts deck (https://ankiweb.net/shared/info/2053137949) . The desk is missing allot of answers, so i started adding information from my favourite source - cppreference.com.

It struck me that a cppreference Anki deck export may be a possible solution. That is questions auto-generated from the cross reference index, (e.g. what is an rvalue). Or a special questions and answers FAQ Page, or a markup for approved questions and answers in each discussion page?. cppreference.com, has the facts of C++ at least, but not all of the the gotcha and best practice answers have questions to reference them.

If it also generated topic filters based on C++ version, class, etc. Then i can use it to filter the cards, to only study C++14 changes for example.

At a minimum it can be exported as tab separated for import. e.g:

What is:${keyword index}<tab>${page keyword(s)}<tab>${html + css for keyword page

That's an interesting idea. Can you elaborate a bit on what you mean by "questions auto-generated from the cross reference index"? I'm not sure if it makes sense to add FAQ-style Q&A here, given the existence of e.g. https://isocpp.org/faq (which you should check out if you haven't already!), but if you can come up with some way of automatically adapting the existing content of the site to make an Anki deck that might be different. --Nate (talk) 07:37, 11 June 2014 (PDT)
I have been playing with it a bit today. Anki renders the cards as HTML in the interface, so i have essentially spammed the default card stylesheet with the cppreference stylesheet to keep the page formatting. It seems that every section/linkable keyword correlates to an 'answer' or concept worth remembering. The hardest part is of course generating questions. My idea (at least for a first approximation) was to generate the card/question list from the section/keyword list + context in tree. Imagine each section as a flashcard. for example:
Q: What is: Operator Overloading (C++ Language, Expressions)
Q: What is: Assignment operator (C++ Language, Expressions, Operator Overloading)
Q: How do you use: std::basic_string (C++, Strings library)
Remember content repetition is a feature not a bug :). If the concept is reasonably viable, then making it smarter/better could be the next step. I would share the deck i am working on, but i have not added any (c) references to the answers, so don't feel comfortable doing so. -- Timoc (talk) 08:26, 11 June 2014 (PDT)

[edit] Experimental standard libraries

I think it's worth start to document the experimental standard libraries. The namespaces and header names seem to be already decided on and are unlikely to change. The following is my suggestion of how everything could be organized:

  • A new row is added to the main page just above the useful links and C++ libraries row. The libraries are listed in similar style as the libraries that have already made into the standard.
  • All experimental libraries are placed under cpp/experimental/*, where * identifies the library, e.g. fs for filesystem, optional for optional, etc.
  • Since the std::experimental namespace is long and some libraries are put into children namespaces, we won't be able to consistently follow our policy of always qualifying all names. I suggest to relax it; a full proposal is below.
  • All dcl items will have markers like (filesystem TS). We may even want to make links from them to a description somewhere.
  • The specification always follows the most recent draft (unless the draft is ratified in some way).
  • Once the functionality is included into the standard, we add a second description of all functionality. A notice is added to the old pages: "The functionality was included into C++XX with the following changes: XX, YY, ZZ". This separation would reduce the clutter on the new standard. While the same can be said about changes between standards, I expect that much fewer people will be interested in changes between the standard and experimental specifications.

Any opinions? --P12 17:19, 4 March 2014 (PST)

I would certainly like to see the new TS specs made available here - this looks like a reasonable plan of action. --Cubbi (talk) 18:54, 4 March 2014 (PST)
This sounds reasonable. My only concern is that the TS items could be confused with standard items, but I suspect that can be addressed with appropriate visual cues. Perhaps we could make (filesystem TS) appear in a different color and include some sort of similar color change on all pages under experimental/? --Nate (talk) 21:17, 4 March 2014 (PST)
Does this mean we can add the Decimal TR now, too? People are working on its new version, which will be a Decimal TS, but its 2011 ISO TR form already saw some limited support. (for consistency, its path would probably best be experimental/? too, even though the namespace is std::decimal) --Cubbi (talk) 09:38, 5 March 2014 (PST)
I guess so... Are there large differences between the TR and TS? --P12 12:00, 5 March 2014 (PST)
There shouldn't be. It may not even become a TS if n3871 gets merged into C++17 directly.(checked with the author - that's the plan, the new C decimal TS wasn't looked in yet) --Cubbi (talk) 12:41, 5 March 2014 (PST)
Should additions to existing libraries be added to the standard library pages or should they be limited to the experimental section? E.g. does uses_allocator_v belong in the current uses_allocator page as a helper type? Luksy (talk) 19:24, 15 June 2014 (PDT)
This wiki already brings up other standards (namely, boost and POSIX) and individual compiler implementation options in the Notes sections of many individual pages: I think that bringing up experimental standard extensions to existing library components makes perfect sense on the pages of those components. On the other hand, posting entire TS specs might make the standard pages less readable. Then again, tiny additions like uses_allocator_v won't take a lot more space than a link. I imagine a good place for that, in any case, would be in or just under Notes: the top of the page is often too crowded already, and few people look at See also. --Cubbi (talk) 08:15, 16 June 2014 (PDT)
Would it not be better to have a cookie that allows users to configure which standard(s) to show? It'd be great to be able to visit something like the vector constructors and only see the declarations valid for 98/11/14, if I'm using C++11 for instance I'm usually not interested in seeing the older declarations. A set of checkboxes could allow users to enable and disable standard versions and TSs independently. I realize this is a lot of work and perhaps a little pie in the sky, still I think it would be a nice addition and would help for implementing the TSs as well. Luksy (talk) 00:13, 17 June 2014 (PDT)
That cookie already exists: enable the standard revisions gadget, you will get a pulldown menu to choose the desired view (diff/03/11/14). Not sure about the feasibility of a TS view (14+every TS?).. P12 developed that functionality (I think), I'd wait for his comment. --Cubbi (talk) 05:58, 17 June 2014 (PDT)
That's great, I had no idea! I wouldn't think a flag would be needed for every single TS, but the library extensions make a number of small additions and changes in a few places so I thought it might be useful for that at least. Luksy (talk) 16:34, 17 June 2014 (PDT)
I was just looking at the Parallelism TS, and it adds an overload to 70+ existing algorithms. Tempted to just put them in with (parallelism TS) -- visibility is a good thing, and C++14 additions are pretty much done anyway. --Cubbi (talk) 08:38, 1 July 2014 (PDT)
A "14+TS" view doesn't sound too unreasonable, and I certainly like the idea of making these changes visible. How should we reconcile the existing separate TS sections that we currently have with the "inline" parallelism TS info? It would be good to agree on a general strategy for how we are going to include TS info in the future. --Nate (talk) 19:10, 1 July 2014 (PDT)
Since TS is allowed to change the standard (with implications discussed in n4041), How about we change the mainline wiki where a TS changes core language or anything in namespace std (as opposed to std::experimental). Actually by that logic the parallel overloads of the algorithms end up in the parallel TS page, since they are, I think, all in std::experimental::parallel. --Cubbi (talk) 20:54, 1 July 2014 (PDT)
I like it. Unless we get objections from e.g. P12, I'd say we should do this in the future. --Nate (talk) 08:22, 2 July 2014 (PDT)
I like it too. BTW, since I have more free time now, it's likely that the standard revisions gadget will be finished soon. --P12 12:30, 2 July 2014 (PDT)

[edit] Relaxing the policy of always qualifying all names

Inclusion of experimental libraries will result in some components that have very long fully qualified names, e.g. std::experimental::filesystem::recursive_directory_iterator (extreme case). This makes following our policy of always qualifying all names not practical to follow consistently.

Also, one of the original reasons for full qualifications will disappear in the near future. I'm developing a new syntax highlighting plugin that will correctly make links to names even without qualification. So even the std:: prefix will become not strictly needed for practical purposes.

My proposal is as follows:

  • The page title will carry fully qualified name as before
  • Examples and "possible implementation" sections will contain qualified names (possibly using namespace aliases) as before.
  • Any other uses (including declaration in dcl items) will use unqualified names.
  • At the beginning this relaxation will only apply for the experimental features. Once the new syntax highlighting plugin goes live we can remove the std:: prefixes too.

What do everyone think? --P12 17:19, 4 March 2014 (PST)

I think having syntax highlighting for shortened names will be great for long names like your recursive_directory_iterator example. How about we begin by using shortened names in new content when they would otherwise be awkward and see how it looks? (It's less clear to me how much of a win it would be to change e.g. std::vector to vector.) --Nate (talk) 21:34, 4 March 2014 (PST)
That's OK with me. --P12 13:57, 16 March 2014 (PDT)

[edit] Disappearing text problem

The last couple months or so I have been experiencing a strange issue where some or all of the text on the page would be the same color as the background. Here is an example: http://i.imgur.com/F8FPMrO.png - It can happen on any page, including the main page. Sometimes refreshing the page fixes it, other times refreshing the page makes it worse. I'm using Google Chrome on Windows. LB(T|C) 11:51, 10 March 2014 (PDT)

Strange. Has anyone else experienced anything like that? --P12 13:12, 10 March 2014 (PDT)
I experienced that a few times last week or two, sporadically, also using chrome for Windows. I was suspecting our corporate web filters and was hoping to see it happen at home (chromium/linux) before I'd report it here. --Cubbi (talk) 13:23, 10 March 2014 (PDT)
I suspect it might have something to do with the fact that we use @fontface declarations to load custom fonts. In this page, when the text disappears, does the red text disappear too? --P12 13:40, 10 March 2014 (PDT)
Just reproduced for me red text is visilbe. --Cubbi (talk) 15:31, 10 March 2014 (PDT)
Okay, that means we need two widely supported fonts (one regular and one monospace) that would have roughly the same cap and median heights. Suggestions? --P12 15:42, 10 March 2014 (PDT)
I think this is a bug in Chrome (https://code.google.com/p/chromium/issues/detail?id=336476). Has anyone noticed this behavior in any other browsers? --Nate (talk) 09:21, 11 March 2014 (PDT)
I have seen it on Firefox on Linux as well, but much less frequently. On Firefox, the most common case is for the text to appear several seconds after the page otherwise finishes loading. On Chrome, the text sometimes does not appear at all, and sometimes reappears after a refresh. I do, however, seem to recall a (single) case where the fonts did not show up on Firefox at all. Shachar (talk) 23:23, 1 April 2014 (PDT)

[edit] Compiler support

I think it's worth to have a page listing compiler support of newly introduced C++ features, because we've started documenting various technical specifications and there's no webpage lists compiler support for these anywhere on the internet. As there was a discussion about this same thing previously, I've just went ahead and added a new page at cpp/compiler_support. The information has been sourced from the stdcxx wiki. --P12 18:32, 20 March 2014 (PDT)

I think it's going to be very hard to keep that usefully up-to-date. Could we at least provide links to the compiler's pages? Clang/Libc++ keep excellent lists: clang (note they started listing the TS's already) libc++ C++14 (looks like they took down C++11 chart for the library since it was 100% back in 2012). Also, the infamous GNU libstdc++. I guess I'll add Oracle compiler status and review IBM's since I use those compilers daily. --Cubbi (talk) 18:58, 20 March 2014 (PDT)
We don't need to be sure the page is absolutely up-to-date. Checking for newly supported features only needs to be done once a month or so. Thus it seems to me that it wouldn't take a lot of effort to maintain the page. As for the links, of course, I think we can link to the official lists for each compiler. --P12 11:01, 21 March 2014 (PDT)
I would find such table to be useful if it had more entries, e.g. match clang++'s tables list. But filling that in for various compilers would be a full-time research project on its own. --Cubbi (talk) 16:44, 22 March 2014 (PDT)

[edit] Concentrated iterator invalidation section

I'm thinking of adding a section to each container saying under what circumstances the iterators are being invalidated. Currently, this information is only available under the specific operations, and getting a global view is difficult. Iterator invalidation is one of the most confusing aspects of working with STL, and this will, I think, make it much clearer. Shachar (talk) 23:26, 1 April 2014 (PDT)

Seeing as the rules are different for almost every individual operation x container combination, do you have a layout in mind that would make them clear? A table perhaps? --Cubbi (talk) 10:09, 2 April 2014 (PDT)
I did unordered_map. It needs some formatting, but I think it turned out fairly concise. My choice was, indeed, a table format. Shachar (talk) 10:27, 2 April 2014 (PDT)
This seems like useful information; I'm for it. Maybe some of the formatting could be borrowed from other tables we already have, e.g. at the bottom of cpp/container. --Nate (talk) 11:25, 2 April 2014 (PDT)
I think such table could included into all container pages just below the current description. I've already pasted your table here. Thanks for bringing this up! --P12 12:14, 2 April 2014 (PDT)
I already put a link to the page at the bottom of that page, so the information is, effectively, there twice. Personally, I think a separate page works better, but I don't feel particularly strongly about it. Shachar (talk) 19:54, 2 April 2014 (PDT)
BTW I think we should have this information in cpp/container too. --P12 12:16, 2 April 2014 (PDT)
I find reference/pointer invalidation to be just as important, if not more that the iterator invalidation. Shouldn't the new subsections include that as well? --Cubbi (talk) 07:14, 12 April 2014 (PDT)
I think that would make sense. --Nate (talk) 06:54, 14 April 2014 (PDT)

[edit] Dealing with large version-specific chapters

When big chapters (like the 'Return type deduction' chapter in cpp/language/function) are enclosed with template {{rev}}, the (C++11)/(C++14) sign become unconspicuous and the effect of {{rev}} probably confuse readers, should some other format be used to solve the problem? --D41D8CD98F (talk) 00:27, 7 June 2014 (PDT)

I agree that's an issue. --P12 13:09, 24 June 2014 (PDT)
Previous talk with Cubbi. Similar problem appears in the page cpp/language/eval_order. (if revboxes were wrapped around both sections Sequenced-before rules (since C++11) and Sequence point rules (until C++11), they would almost occupy the whole page) --D41D8CD98F (talk) 04:14, 29 June 2014 (PDT)
I guess we need a separate template for this. --P12 12:23, 4 July 2014 (PDT)

[edit] RFC: Integration of standards revision gadget

We are thinking about enabling the standard revisions gadget by default for all users. This will alter the way information is displayed relatively significantly, thus it's worth to discuss with the cppreference users before implementing the changes.

Standard revisions gadget basically does a single thing: hides information that is not applicable to a certain standard version selected by user. Such tool becomes more and more necessary as the number of C++ standard revisions grows; the readability of part of the documentation is already reduced (e.g. here).

In the current plans, the standard revision gadget will work as follows:

  • This can be overridden by a separate 'standard revision' menu that we already show. If non-default revision is selected, a HTTP GET parameter is appended to the URL. All links are modified to preserve the standard revision override. The override can be easily cleared via a button. There are keyboard shortcuts to select a standard revision override.
  • Depending on the values of the default standard revision setting and standard revision override, unnecessary information is hidden. It's already possible to try this by enabling the standard revisions gadget in the preferences. Note that the gadget hasn't been completely finished yet.

The above should work in the following use cases:

  • User wants to link to the documentation for specific standard. He selects a standard revision in the menu and pastes the contents of his URL bar somewhere. For example: http://en.cppreference.com/cpp/container/vector/insert?std=cxx11.
  • User browses the internet and finds a link to the documentation of specific standard. He clicks it and the correct documentation is displayed. Personal preference is temporarily overridden (but only on that tab). The user can continue to browse or exit to his preferred documentation any time by clicking a button.
  • The user wants to temporarily browse the documentation of standard that is different than his preferred, but doesn't want to affect other tabs. He simply selects the standard from the menu.
  • User uses a specific standard for most of his work. He wants that the preferred standard is selected automatically whenever he comes to cppreference.com from the results page of some search engine. He selects the default/preferred standard revision.
  • Users without Javascript will have the same experience as now.

Any thoughts and suggestions? --P12 13:47, 8 July 2014 (PDT)

I think it's implied, but to be clear, the "Diff" view remains available, right? A use case I've seen more than once was user can't compile code, looks up the function from the error message on cppreference, sees "(since C++11)" next to it and learns about compiler options. --Cubbi (talk) 14:17, 8 July 2014 (PDT)
Yes, certainly. --P12 14:19, 8 July 2014 (PDT)
I tried enabling the standards gadget on my personal preferences and then viewing pages. However, nothing happens when I select different values in the combobox. It's hard to say whether or not this should be enabled by default when it doesn't appear to work :-). --Legalize (talk) 10:14, 24 July 2014 (PDT)
Could you test it on this page? The changes should be easily seen. If nothing happens, then it's indeed a bug and I'll be very interested in what browser / extensions do you use. --P12 04:42, 25 July 2014 (PDT)
I'm not sure what happened, but at some point it started working for me. --Legalize (talk) 09:07, 4 August 2014 (PDT)

[edit] Delay until text appears

This is related to the "disappearing text problem" noted above, though I think it deserves a separate entry since it's not quite the same as the description at the top of that section. When viewing the site using Safari (e.g. Safari 7.0.6 (9537.78.2)), I usually observe the following: first, much of the site's layout appears, but with no text visible. After a few seconds, the text then loads. I strongly suspect this is due to the use of custom font faces, since, for example, big-O complexity text shows up right away. For what it's worth, the same thing also happens for me on Chrome (37.0.2062.94 on Mac), and it seems to be exacerbated by slow network connections. Sdt (talk) 16:06, 8 September 2014 (PDT)

[edit] Page with list of needed/requested articles

Is there any page with list of requested articles? If not, I suggest to create one. Rutsky (talk) 01:52, 10 December 2014 (PST)

It's mentioned in the FAQ: Pages that could use examples, Pages marked with specific todo items, Pages marked with general todos. Plus, as with any wiki, there is Special:WantedPages --Cubbi (talk) 03:24, 10 December 2014 (PST)
Thank you for comprehensive answer, Cubbi! Actually I was interested to request pages that 1) will explain some concepts of С++ (e.g. "incomplete type") or 2) will give advices on patterns (e.g. "copy and swap idiom"). Consider second: is Cppreference has place for articles such as programming idioms (like WikiBooks' https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms)? I see that there is book (http://en.cppreference.com/book/Main_Page) with general information (not only C++ reference). And consider first, I actually failed to find some information on this site due to bad built-in search engine — see my next post. Rutsky (talk) 13:18, 17 December 2014 (PST)
incomplete type is cpp/language/type#Incomplete_type also accessible as cpp/language/incomplete type, as you found out. As every standard language concept, it should be featured under cpp/language (in my opinion). I agree that discoverability of core language concepts is poor. One application of compare-and-swap is discussed under copy assignment and again under operator overloading.
As for the idioms in general, it's been discussed on one of these talk pages a while ago, I think the consensus was weak agreement; that's why I added cpp/language/raii and cpp/language/rule of three. Objections to consider:
  • Idioms are not really reference material and may get rather subjective unless discussed in Bjarne's books or similar caliber references. They may work better as a section of the book (might increase interest in it too).
  • Idioms are already covered by another wiki (that wikibook, specifically), why not help them improve it instead of forking the content across the web? --Cubbi (talk) 13:54, 17 December 2014 (PST)

[edit] Built-in search on en.cppreference.com works bad

Often it's not possible to find even exact matches on en.cppreference.com site using built-in search.

For example:

I think search results can be improved by configuring current search engine or by switching to other search engine (I see that there are plenty of them: https://www.mediawiki.org/wiki/Fulltext_search_engines). Also one search index should be used for whole site. Rutsky (talk) 13:18, 17 December 2014 (PST)