Talk:Main Page/Archive 2

← Archive 1

Archive 2

Archive 3 →

Search for "remove" does not show the C++ algorithm

If you search for "remove", you only get a link to the C function (to delete a file) and not the C++ algorithm. It seems both should be displayed, or there should be a way to get to the C++ one. Jaredgrubb 08:30, 11 July 2013 (PDT)

Yeah, this isn't optimal. We also have a similar problem with "std::move", which could refer to cpp/algorithm/move or cpp/utility/move. It's not limited to search results, either: the automatic links in code examples have the same problem.

It might be worth thinking about a general solution to all of these problems...perhaps something like adding an optional field describing how an item should be rendered. For example:

• "std::move" could work as it currently does, i.e. links to cpp/algorithm/move but renders as "std::move"
• "std::move_1" could link to cpp/utility/move but would also be rendered as "std::move"

--Nate 14:48, 11 July 2013 (PDT)

Status of Filesystem TS WD

Does anyone know whether there are any large scale changes pending for the Filesystem library working draft? Maybe it's worth to start documenting it? --P12 17:13, 24 July 2013 (PDT)

Do you mean http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3335.html ? --Nate 17:43, 25 July 2013 (PDT)

There's newer one -- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3693.html. It's not a proposal anymore, but a working draft. --P12 06:19, 26 July 2013 (PDT)

I chatted with Beman Dawes: He says that n3693 is very complete, but it might be wise to wait until after the Chicago meeting on 9/23-9/28, as there are some minor changes (including the choice of sub-namespace within std) that would be annoying to write and then fix. The filesystem TS from that meeting (which will be available around 10/16) should be final. --Nate 10:37, 1 August 2013 (PDT)

I agree, it makes sense to wait for the final TS. P12 06:51, 4 August 2013 (PDT)

It seems that the filesystem TS is still in WD phase unfortunately. The new n3790 hasn't been changed much compared to the previous version. --P12 03:40, 18 October 2013 (PDT)

A followup from Beman suggests that it's close, but there are still a few names to be decided:

"The biggest change I'm expecting when the committee does ballot resolution changes at the February meeting is for the header name to change, probably to <experimental/filesystem>, and the sub-namespace name to change from 'tbd' to 'experimental'."

Given the annoyance of renaming things, perhaps it makes sense to hold off until February? --Nate (talk) 10:57, 18 October 2013 (PDT)

I'm fine with waiting -- my reply was just an observation. In any case, I already have a semi-complete reference on my local development wiki, so I'll have to do a search/replace before importing the content here anyway. --P12 12:12, 18 October 2013 (PDT)

Thread safety

Currently we include an explicit description of thread-safety of functions on only one case -- when a function is not reentrant. However, any data race can cause function to be thread-unsafe for particular usage. Possible data races are not obvious most of the time, thus I guess it would be a good idea to explicitly specify thread safety of all functions.

The information on thread-safety could go to a separate section, between the complexity and notes sections. I'm a bit unsure as to what title for the section we should choose? Currently I'm thinking about simple "thread safety", though "data races" may be also a good candidate (cplusplus.com uses this one).

Any opinions?

P12 05:29, 16 August 2013 (PDT)

The standard guarantees for thread safety in C++ library functions are in 17.6.4.10[res.on.objects] and 17.6.5.9[res.on.data.races]. I am not sure how meaningful that would be to repeat the text for every function, although it is definitely worthwhile to put it somewhere on the wiki. Only a handful of functions are "not required to avoid data races", which I think we've all documented, although more-or-less informally. From what I see on cplusplus.com a lot of what appears under 'Data races' there is not at all guaranteed by the standard. I wouldn't mind using BSL classification (minimally/const/fully thread-safe, thread-aware, thread-enabled), but even that would be a little boring (const-thread-safe, almost every single page). --Cubbi 07:10, 16 August 2013 (PDT)

(edit) oh, yeah, also 23.2.2[container.requirements.dataraces]/1 with its list of container member functions that are const for the purposes of 17.6.5.9.. maybe it can be phrased into something helpful for individual container member functions. --Cubbi 18:07, 17 August 2013 (PDT)

It does seem a little repetitive to have "const thread-safe" on every page. Maybe it would make sense to start by making a single high-quality page explaining the thread-safety guarantees made by the standard, and then see how much traffic it gets/how discoverable it is. If people can google up a clear answer about thread safety in the standard library, then perhaps we don't need to repeat it over and over on every page. --Nate 17:17, 19 August 2013 (PDT)

Including clauses from the official standard

There are times I'd like to quickly check the C++11 standard for additional information on a topic here at cppreference. I think including the clause number so you could quickly refer to it in the standard would be convenient. Placement of the clause could be directly before the topic title for example: 21.4 std::basic_string What do you think? William Dang 16:03, 26 August 2013 (PDT)wdang

I think it's an interesting idea. There's some discussion about the possibility of a "References" section over at http://en.cppreference.com/w/Cppreference_talk:FAQ, under the section "Reference to c++ standard". It's a little more extensive than a single reference under the topic title, but it should achieve a similar goal, no? --Nate 17:32, 26 August 2013 (PDT)

Yes, that would achieve a similar goal. I didn't know it was already being discussed. Thanks for the heads up. William Dang 18:31, 26 August 2013 (PDT)

Abandoning complex templates

After some considerations, I arrived to the conclusion that in some places of the wiki the templates are unnecessarily complex and we all would be better off if we simply duplicated text. The content is mature, so the benefit of avoiding several identical edits from time to time is heavily outweighed by the fact that the new editors can't cope with the complexity. What do others think about the prospect of gradually abandoning complex "page templates", such as {{cpp/container/emplace_assoc}} (be sure to look at its source)? --P12 16:45, 28 August 2013 (PDT)

Difficulty editing has been the most common feedback I've heard from the Stackoverflow folks (as in "I wanted to correct vector::insert, but the edit box is empty"), I think this would be helpful. --Cubbi 18:37, 28 August 2013 (PDT)

I'm okay with this. Let's not do too much denormalization too quickly, lest we end up back with the original problem. But fixing pain points as they occur sounds fine. --08:42, 29 August 2013 (PDT)

"C++ book": an educational section on cppreference

After some discussions with Nate, we agreed that it makes sense to create a new section on Cppreference with much broader scope than the current wiki. The current policy of focusing on the C++ standard often results in documentation that is difficult to understand unless one knows lots of C++ already. By putting this complementary material into a separate section, it becomes possible to cater to novices without reducing the readability of material intended for experts.

While there are lots of C++ resources around the internet already, we believe that Cppreference has two very important advantages: it is a wiki, and it already has a great community of professional C++ developers. This has allowed the website to achieve the completeness and accuracy it has become widely known for. We hope that with the help of the community we can maintain the high standard of quality even for vastly expanded amount of material.

Including new content under the umbrella of Cppreference also has the benefit of the level of integration that is not otherwise possible. For example, the discovery of the new possibilities that the newly integrated Coliru online compiler provides[1] was a major factor that has led to this initiative. Just imagine a novice who is able to modify and run an example without the inconvenience of copy-pasting the source code and intricacies of setting up the build environment! The user experience of the basic tutorials will be much higher than what's currently available *anywhere*.

We will not be able to implement this idea without huge help from the community. If you are interested in contributing, please mention that you can help below[2]. Comments with interesting ideas are welcome.

--P12 15:05, 6 September 2013 (PDT)

[1] many thanks to Francis Rammeloo for creating a public API

[2] note, that the project won't be started if there's not enough interest. Thus, if you're indeed willing to help, a simple "me too" message is very valuable.

A rough sketch of what the C++ book could look line is outlined below:

• The C++ book is maintained in a new instance of MediaWiki at http://en.cppreference.com/book
• NO INSANE WIKICODE TEMPLATES. If you can improve Wikipedia, you will be able to improve the C++ book too.
• The content is written mostly in prose, something like C++ programming book on Wikibooks.
• The scope of the C++ book - anything that can help one to become a better C++ developer.
• Overall structure is similar to one of the current wiki.
• The C++ book is organized into two or three sections ('beginner' and 'advanced' or 'beginner', 'intermediate' and 'advanced').
• The 'beginner' section contains the most basic content: the assumption is that before reading it the user does not know anything about C++ and programming in general. The section will teach variables, arrays, pointers, functions, some parts of the standard library, etc. etc. and a simplified introduction into templates. The subsections would be ordered in such a way, that it would be easy to read them sequentially.
• In the 'intermediate' section it is assumed that the user already knows what's in the 'novice' section. This section contains the expanded descriptions of the bulk of the standard library, plus advanced usage of templates, etc. There's no sensible subsection ordering within the section.
• The 'advanced' section contains anything that's "very complex" and/or "useful only in large projects". For example, design patterns could be explained here, etc. The intermediate and advanced sections possibly could be a single section though: any prerequisites that the user must know could be listed at the top of each page.
• Stackoverflow could probably be a good source of what and how to describe, especially the most voted answers.
• There are plenty of great articles, such as this, on the internet. It would be great to collect what they say into a single place.
• A fork of More C++ Idioms book on Wikibooks would be good to have.
• All content of the current wiki is be covered in the C++ book. They will complement each other very well: the current wiki will describe the what a function, class, etc. does, whereas the C++ book will explain how to use it, pros/cons, alternative approaches, important things to consider, etc.

--P12 15:05, 6 September 2013 (PDT)

I think it may be too much of an undertaking. Perhaps I am overly cautious because I've written programming books in real life and can look back at the amount of hard work it takes before it becomes complete enough to be useful.

Looking at your points, I think you are really suggesting two books, differing by intended audience, style, and presentation:

1. a new (freely-editable and peer-reviewed) online C++ tutorial

that's something that the web needs, I agree (to quote the Stackoverflow C++ book list, "There is a reason nobody bothered to setup a similar question for online tutorials."). I occasionally consider what it would take to start one myself, but find it a much better use of my time to improve the reference here instead. Unlike the reference, which can always point back at the standard whenever someone raises a concern, any tutorial would be highly subjective, and its layout would be essentially determined by its first contributor. For example, I would of course bring up vectors and strings far ahead of arrays and pointers (like every beginner textbook listed in the SO book list does), but I'd also bring in unit tests (and introduce an early dependency on some unit test library, likely boost since I can't imagine C++ development without boost anyway). I am sure plenty of people would suggest a different presentation, reflecting their own understanding, experience or background, but it's almost impossible to revamp the structure of a tutorial once any amount of work was put in.

2. a collection of intermediate-to-advanced articles on C++

public-submitted C++ article repositories have been done enough times, even cplusplus.com maintains one. One of my favorites, the Stackoverflow c++faq, is even editable and quality-controlled, yet it covers only a few high-profile, frequently asked, topics. I think "All content of the current wiki" cannot be covered: the C++ library alone takes several books to explain (Josuttis, Langer/Kreft, Williams), and many parts remain unexplored even then. The way More C++ Idioms went, with discussing individual best practices, is nice to link to once in a while, but its discoverability is pretty low: the index page with idiom names says very little.

I would suggest a more limited, strictly defined focus for something to start with.. but I don't have a good idea of what it could be (if I did, I'd be writing one myself!) --Cubbi (talk) 16:34, 6 September 2013 (PDT)

Lots of things depend on how many editors are interested in actively helping. Seeing that so far there's very little interest generated, I concur that it indeed is necessary to limit the scope at the beginning (or either not start the project at all). But in the long term, I hope we'll be able to expand the objectives till those outlined in the original proposal -- Wikipedia was not written in a day too, but look at it now. Being a wiki is a tremendous advantage in this regard.

Considering (2), a simple collection of articles is not the objective. I think that, for example, if we try to explain rvalue references, we'll end up with something like this anyway. In any case, implementing (2) is off the table for now. The discussion can be postponed until we have at least some content in the C++ book, so that we see what to base the efforts on.

The initial scope could be the most basic tutorials, perhaps what I've outlined for the 'beginner' section. Once the tutorials are at least somewhat complete, we can start a new phase.

Does that sound right? --P12 03:59, 7 September 2013 (PDT)

I agree, have book/tutorial and online examples in one place and without copy-pasting and setting up the build environment is very good idea. I saw one example: www.codeschool.com (Tutorials only. I don't like how it's implemented, but the idea). Of course, fork/merge existing resources can be a good start. Ruslo (talk) 02:34, 7 September 2013 (PDT)

I like the idea but if different people start writing different sections it's very likely to become more of a collection of micro-tutorials rather than a single book. In my opinion the book will need some strong guidelines on the overall structure of the book and on the layout of the single pages. --Bazzy 13:49, 7 September 2013 (PDT)

Given that the content is editable by everyone and can be peer reviewed, I hope that the difference between a collection of micro-tutorials and a regular book will be pretty minimal. We just need to ensure that each tutorial covers only a single subject and that there are no holes in the total subject coverage. After all, books are divided into sections covering different subjects too.

Having said that, there might be cases where duplication is actually beneficial. For example, the same subject may be covered by several tutorials, each of which is written having readers with vastly different levels of C++ knowledge in mind.

I think that it makes sense to add rules on the layout only after we have some content and see what actually works best. The same is with overall structure of the book, though I have a feeling that it will be enough to discuss a few times as we probably won't need to change the structure often.

--P12 15:03, 7 September 2013 (PDT)

Writing a whole book from scratch might be too much of an undertaking. I think it would be prudent to consider a collection of "how-to" articles that are of manageable size, e.g., "collections", "pointers and references", "strings and standard io", "ctors, movector, dtor, copytor", etc. Once a sizeable amount has been written, a single book-entity could be derived. There are plenty of C++ sources out there already, so tightly integrating this with coliru would really set it apart from the masses. A book that already uses an online editor is Eloquent JavaScript I suggested we source some inspiration there. --Keepsake 12:21, 8 September 2013 (GMT)

I agree with a lot of the sentiment here about the difficulties of collaboratively writing about subjective material. Writing about the C++ standard has several features that make collaboration easier:

1. The layout and organization of the standard suggests a natural structure for the writing.
2. The content is easy to divide into small pieces, which allows many people to make changes independently of others.
3. The standard is a "higher authority" that can be very helpful in resolving disputes.

I suspect that the success of a collaboratively-edited tutorial will depend on how many of these features we can provide to editors. For example, focusing on small "micro-tutorials" would help achieve (2) and to some extent (3) (since it would minimize debate about subjective things like presentation order and deep structure). --Nate (talk) 05:57, 8 September 2013 (PDT)

I'm interested in helping out, having reviewed a book on C++ Programming recently. -- Deanberris 03:00, 9 September 2013 (AEST)

I have actually thought this would be a useful extension to the existing cppreference content for a while now. It's handy to have a terse reference to what a function does, but sometimes that's just not enough - especially when the function really needs to work in tandem with other functions. Even a web of "see also" links just isn't good enough.

I also don't buy most of the objections I've seen so far. "It's too much work" doesn't make sense in the context of a wiki, which is designed to be built bit-by-bit (as opposed to a traditional book, which has to be more-or-less completely built before it is useful) - a bunch of redlinks at the start of the project is hardly going to be its death-knell, and they'll be gradually filled out. The same logic applies for "the scope is too big"; it'll get done eventually, and the more useful/wanted things will just naturally get done first.

As for "too many cooks spoil the broth", I don't see that it will be a problem if a small group of people are dedicated as "book editors", who decide the grand structure and format, while everyone else is tasked with writing content in smaller, bite-sized bits. The "book editors" could simply maintain "what we need" lists, possibly prioritized, that editors can chip away at at their own pace.

In general, just because there's a lot to do before it's "useful", it doesn't follow that it can't or shouldn't be done. The wiki design is ideal for chipping away at a big project. As I recall, one of the wiki mantras is "be bold".

Of course, I'll do my part, too. -- Indi (talk) 01:36, 10 September 2013 (PDT)

I'll do Varun (talk) 01:19, 11 September 2013 (PDT)

I'll help -- I've written two IBM Red Books in the past, and have training/teaching experience with C++, but apparently have a lot to learn about Wiki's ... Update: I'll be taking an LoA from my job starting next Monday for a few weeks, I'll work on a few sections next week. Sorry for the loss of signal, but I've been dealing with the reason for the LoA. DRaymer 1030 CST 7 OCT 13

Thanks. --P12 05:45, 8 October 2013 (PDT)

Update: I've opened a test wiki at http://en.cppreference.com/book. I think it's worth to continue the discussion [[1]]. If anyone wants to write a tutorial on one subject or another, you can do so now. --P12 04:32, 12 September 2013 (PDT)

I can try helping out! I suggest we may want to consider adopting something like a "coding style" (perhaps a writing style) to avoid bad/C-style issues plaguing most (if not all) currently available C++ tutorials (I'll try to elaborate upon this on the book's discussion page). Md (talk) 09:05, 13 September 2013 (PDT)

I am willing to contribute to the book. I am very passionate about documenting and writing. Satishgoda (talk) 21:52, 18 December 2013 (PST)

Contributors wanted

Me too! Syd Musavi, René Eng

What is the playground page for?

What exactly is this page for? Its name seem to imply that it's some sort of vandalism. I've looked into the history and found this hilarious version of the page that links to some seemingly useful pages but also mentions <dragon.h> (which is apparently supposed to create a magic creature or something) and links to cpp/dragon/call_dragon and cpp/dragon/receive_fire, and both of those pages have lots of links pointing to them. Also note that most of the edits there are made by P12 which seems to make quite a lot of helpful edits, so I highly doubt if it's a vandalism or not. Note: I've found that page via Special:LonelyPages and Special:DeadendPages. Theemathas (talk) 06:47, 15 October 2013 (PDT)

The playground is a special non-permanent page that users can use to make "test" edits, and otherwise explore mediawiki functionality. The idea is to encourage people to mess around in a sanctioned area rather than real content pages. People with accounts also use their user pages for that type of thing. --Nate (talk) 09:07, 15 October 2013 (PDT)

Compiler support

Does anyone have any thoughts about adding a page that describes compiler support for various features, e.g. something akin to http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport (which has been frozen)? Perhaps under http://en.cppreference.com/w/cpp/compiler_support, or maybe http://en.cppreference.com/w/cpp/language/compiler_support ? --Nate (talk) 06:35, 24 October 2013 (PDT)

It looks like the linked to page is on a wiki and is simply not updated. I guess this wouldn't be a problem for us as this wiki gets much more traffic and barrier for editing is lower. Thus I think it's worth to have such page. I vote for cpp/compiler_support. --P12 08:41, 24 October 2013 (PDT)

Anchored links idea

One feature of documentation that I like is being able to link directly to parts of a page. For example: http://docs.valence.desire2learn.com/res/user.html#get--d2l-api-lp-(version)-users-whoami . On these docs you can hover over any of the routes or data types and a backwards-P symbol will appear, linking to that element. When an anchor link is used, the associated thing is highlighted in yellow.

What I like about this design is it is visually unobtrusive (the widgets are hidden until you hover) and yet serves a very useful function. (Use cases: "check the 3rd overload on this page", "check out the possible implementations section" --> both can be made easier by just linking directly to the subject, plus a highlight.)

I did a quick mock-up using some cppreference pages, here are two examples:

http://csclub.uwaterloo.ca/~j3parker/things/cppreference_anchors_mockup/vector.html#dcl_2 http://csclub.uwaterloo.ca/~j3parker/things/cppreference_anchors_mockup/count.html#Example

If you hover over any of the sections or any of the declarations at the top an orange backwards-P doodad will appear with a link.

This could presumably be implemented in the global CSS + related templates.

Do people find this interesting? I'm willing to do the work for it if desired.

--JacobParker (talk) 19:54, 9 December 2013 (PST)

I think this would be a useful addition to the site. Before I looked at your demos, I assumed that you'd need to inject a bunch of <a name="..."> tags into the DOM at various points, but it looks like that's not the case -- can you elaborate a little bit about what kind of CSS and mediawiki template changes this would require? --Nate (talk) 08:57, 10 December 2013 (PST)

Headings are not templates, thus AFAIK changing their HTML representation would need changes to the MediaWiki core. In my opinion something like a simple Javascript plugin would be an approach that is both easier to implement and more maintainable. --P12 09:03, 10 December 2013 (PST)

I think anchor widgets and highlighting of headings will definitely improve the user experience. The headings are not implemented as templates though, thus we'll need a bit of Javascript that runs after page load to implement it. You can use JQuery 1.8.3.

Linking to specific overloads can be implemented similarly too. One thing to pay attention to is that the overload order and numbering is not static. The former may be changed by an editor, though that happens relatively infrequently. The latter may be changed by scripts: for example, there's an optional Javascript plugin which hides specific overloads depending on the version of the standard selected by an user using a dropdown menu. You'll need to run your script almost immediately after page load, iterate through all the overloads and add the required HTML and CSS classes.

--P12 09:00, 10 December 2013 (PST)

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.

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)

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)

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)

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:

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.

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)

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)