Namespaces
Variants
Views
Actions

Talk:Main Page

From cppreference.com
Replacement filing cabinet.svg

Archives

Archive 1 Archive 2

Contents

[edit] Section about STL naming conventions?

81.173.167.20 18:30, 21 March 2014 (PDT)I've been trying to find a summary of the STL naming conventions (TemplateParameters, types_and_containers, functions_and_function_objects, variables). Would it make sense to put (and maintain) a summary here somewhere?

Well, as far as the user of the standard library is concerned, all names use lowercase_with_underscore format. Template parameter naming is implementation detail; if one looks into any of the implementations of the standard library, all template parameters are almost always uglified (i.e. _Type) to prevent name clashes with user defined macros. --P12 04:16, 22 March 2014 (PDT)
well, std::ios_base::Init uses uppercase, so... that is as long as all names use lowercase goes.

[edit] ASCII chart under C/C++ | Language?

ASCII is neither a part of the language standards nor required by them, but on this site the ASCII chart is listed under the Language sections of C/C++. This is incorrect and misleading. 75.37.31.56 15:32, 23 February 2014 (PST)

Yeah, it's kind of a historical artifact. I think I'd be okay with deleting it -- there are plenty of ASCII tables on the net, this one doesn't really add anything new, and (as you say) it risks confusing people into thinking that it's somehow part of the language spec. --Nate (talk) 19:35, 23 February 2014 (PST)
Technically, C++ standard makes references to ISO 10646 and specifically its ASCII subset, but only in very limited scope, e.g. when talking about \x and \u escape sequences or (in the C standard included by proxy) when talking about narrow character classification functions. I do agree that there are other websites that describe Unicode (or its ASCII subset) pretty well already. --Cubbi (talk) 22:44, 23 February 2014 (PST)
I agree that having the chart under 'Language' heading is a bit confusing. On the other hand I think that it's worth to keep it since its usefulness, however small, does outweigh the cost of keeping it. The analytics data say that the page has been accessed a bit more than thousand times last month -- it has roughly the same popularity as pages about strcpy or memset, for example. --P12 10:09, 26 February 2014 (PST)

[edit] This looks horrible

http://puu.sh/6MxFe.png Especially the underscores on the bottom right being in the line below them.

I agree that the underscores a little sub-optimal, and that's something that we might be able to adjust. Is there anything else that is specifically objectionable? --Nate (talk) 20:08, 7 February 2014 (PST)

[edit] Scrolling in examples

Currently long examples are not very convenient, since it's not possible to see the output of code at the beginning of the example without scrolling down. Wouldn't it be a good idea to limit the maximum height of the 'example' element by adding a scrollbar? I'm thinking about something like what's currently shown once the 'run' button is pressed. --P12 08:17, 11 January 2014 (PST)

I wonder if the problem is that we have examples that require scrolling in the first place, as opposed to something shorter that can be viewed without scrolling. Could this be an argument for multiple shorter examples in certain places? Also, do you have a specific long example that you were thinking of? -Nate (talk) 09:12, 14 January 2014 (PST)
Comparatively long examples are quite common. Even this one spans entire screen on my browser, that makes direct comparison between code need scrolling up and down constantly (zooming out helps though).
As for multiple examples, I agree, though perhaps it makes sense to move additional examples to the book project and only add links to them. I expect that eventually the book project will contain large collection of examples for each feature of the library. --P12 01:33, 15 January 2014 (PST)
I agree that the regex example reaches the edge of what I'd consider acceptable length. (My metric is "will it fit on my 13 inch MBA screen".) I'm not a big fan of the UX that inner scrollbars provide (most likely because some sites seem to overuse them, *cough* G+ *cough*) but I can certainly understand wanting to be able to see both the example and the output.
Perhaps we could turn on a max-height scrollbar and also work to split any examples that trigger it into multiple chunks, when possible. Any pages that start to accrue too much example material would then be potential candidates for partial migration to the book project. --Nate (talk) 07:31, 15 January 2014 (PST)
Agreed. --P12 08:09, 15 January 2014 (PST)
Someone was recently arguing at SO against extensive examples at reference sites -- I don't really agree: my ideal reference would show how the subject of the article could appear in an actual C++ program (which is why I feel awkward about examples like std::mutex that call mutex.lock() in a situation other than the constructor of a RAII guard class), important corner cases (who besides us shows the nested std::bind? I know a team that uses it a lot), and push the envelope where possible (like the sorts I added in my first days here to std::rotate and std::iter_swap). Sometimes realistic use requires a lot of code to demonstrate: I consider my example for std::ios_base::register_callback to be over-simplified even though I bet it won't fit on Nate's screen, but I feel that code that just calls that function and does nothing realistic (cplusplus.com MSDN would just lead the readers to believe it's pointless. Although I would agree that if the book project has an "advanced I/O streams" section, it could have a home there with a link from the ref page. --Cubbi (talk) 08:33, 15 January 2014 (PST)
I agree, examples are very useful for understanding how a feature can or should be used. One of the reasons for the book project was that if there is no requirement of conciseness, then we can have as extensive explanation and as many examples as we want. Then we can link to the relevant sections of the book project from the reference and vice-versa and have the best of both. --P12 23:49, 17 January 2014 (PST)

[edit] Style of <code> elements

Isn't the following style more readable: code vs code? --P12 01:41, 15 January 2014 (PST)

For the word "code" by itself I kinda like it. :) Are you proposing that we change the "c" template to have that style? Since this change adds a bit more visual noise, it might be good to consider how it looks in a busier context, like on regex/basic_regex or algorithm/find. --Nate (talk) 07:41, 15 January 2014 (PST)
Here's a busy testcase:

[edit] Old

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.

[edit] New

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.
It actually seems to reduce visual noise while still highlighting code snippets well enough for reading. --P12 08:04, 15 January 2014 (PST)
Yup, I agree. I'm okay with this change. --Nate (talk) 16:03, 15 January 2014 (PST)

[edit] Links to HTML version of the standard drafts

Does anyone know something like this just containing a more up-to-date draft? We could link to such resource from the references section. If the URL structure is appropriate the linking could be completely automatic. --P12 14:45, 18 February 2014 (PST)

I can't get to that page right now, but assuming that it is a HTML version of the standard, it's possible that we could generate our own from github.com/cplusplus/draft using something like Latex2HTML (or one of the other LaTeX -> HTML translators). --Nate (talk) 16:05, 20 February 2014 (PST)
The problem is that C++ standard drafts are copyrighted and contain the following notice:
This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the reproduction of working drafts or committee drafts in any form for use by participants in the ISO standards development process is permitted without prior permission from ISO, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior written permission from ISO.
OTOH I've just now realized that I participate in the ISO standards development too (LWG #2264). Cubbi has submitted one issue also. So I guess having a HTML version of a draft on the website would be OK, wouldn't it? --P12 16:27, 20 February 2014 (PST)
I asked Herb about this, and unfortunately it seems pretty clear that the copyright that the ISO holds on this material will prevent us from generating our own copy. One possibility that he raised, however, is linking to the github source -- we're not sure if it's desirable or even possible, but it seemed worth mentioning here. --Nate (talk) 17:02, 21 February 2014 (PST)
Wouldn't hosting generated HTML on github be another solution? IANAL, but the github source and the resulting HTML should have the same copyright protection, so in principle it should be possible to for them to set up another repository under the C++ committee github organization umbrella and provide access to it via github pages. Of course, this means that certain amount of cooperation from the C++ committee is needed, but perhaps an accessible up-to-date HTML copy would be useful for them too as it would be much easier to spot the bugs for the outsiders. --P12 20:35, 21 February 2014 (PST)
Apparently that won't fly either: the ISO itself (not isocpp.org) is really the only body that controls this material. Herb mentioned the possibility of linking to the various proposals that are out there, but that has the downsides of being non-authoratative and worryingly ephemeral. It's a good idea, but I can't see how it could work well for us. :( --Nate (talk) 17:38, 25 February 2014 (PST)
Indeed, that's unfortunate. --P12 10:10, 26 February 2014 (PST)

[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)

[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)