Neither TR1 (which is now obsolete of course) nor TR2 (far from finished, but already supported in small part (#include <filesystem>) by Microsoft, of all things) are curretnly mentioned on this page. --Cubbi 08:50, 30 April 2012 (PDT)

That's complete rubbish. Aside from the fact that it isn't the latest draft at all but is over a year behind the actual latest draft, the URL of one of the places where members of the public can get a copy of the non-draft standard is right there, above. Jonathan de Boyne Pollard 07:11, 25 March 2012 (PDT)

We can't expect all editors to have a copy of the actual standard as it isn't freely available. Aside from that, the FAQ is surely outdated, thanks for pointing that out. -- P12 08:04, 25 March 2012 (PDT)

Might as well give the C11 ANSI store too (I can't seem to be able to edit this page). --Cubbi 12:08, 24 September 2012 (PDT)

I've relaxed the permissions for this page a bit; you should be able to edit it now, @cubbi. (@p12: we can go back to admin-only write-access for the FAQ if this was done on purpose -- I'm assuming that it makes sense for this page to have the same protection as e.g. the front pages.) Nate 15:57, 24 September 2012 (PDT)

There's indeed no reason why the page should be only admin-editable. -- P12 05:03, 25 September 2012 (PDT)

The limitation width and max-width for the whole page should be removed. I have located 3 of them in the latest HTML-Book-Version, files common/loadfe52.css and common/load7fe1.css. After removing them the pages look much better. My download of the offline version some months ago had the same "bugs". 80.147.4.22 02:49, 4 June 2014 (PDT)

Are you concerned about the width settings for the HTML-book-version or the live site (or both?) --Nate (talk) 06:53, 4 June 2014 (PDT)

All 3 versions, book, Raw and live, have text bodies with fixed width (and centered). At least the non-book versions should have variable width as recommended by W3, I think. Why killing one of the most reasonable features of HTML for nothing? --91.97.19.47 11:45, 4 June 2014 (PDT)

Some boost libraries could also be candidates for inclusion though. While their tutorials are very good, the reference documentation is often very inflexible and inconvenient.

I feel the same way, and every C++ programmer I've spoken to about Boost seems to say the same thing. I really think the inclusion of popular Boost libs on cppreference.com would be incredibly useful to the community.

Is there some way we can come to a consensus on this issue? I realize this would mean a scope change for this wiki, which would raise the question about other external libraries being documented here. From an OOD standpoint, I can see the elegance of restricting the scope of this site to the pure language standards, so perhaps this is a case for a new open source library reference wiki?

Personally, I find their tutorials to be lacking compared to the documentation, but I've been using Boost for many years so I guess I got used to it. I agree that simple examples like the ones we put for standard C++ components would be useful (making a small flood-filled .PNG file with Boost.GIL is two lines, but there is no tutorial that shows how. People see the wall of text about generic algorithms and move on to other libraries). There's still a lot of redlinks in standard C++ library, though. --Cubbi 11:29, 31 December 2012 (PST)

I like this idea. I suspect that the missing piece for getting boost on cppreference.com is finding a person to lead an initial push to get the overall structure of boost docs figured out. The three main issues that I can think of are:

boost is big: I don't have good numbers on this, but based on the sources for boost_1_52 and libstdc++-v3, I'd say boost might be 2-3 times the size of libstdc++. That's a lot of content to cover.

boost is released more frequently: I'm not entirely satisfied with the way that we're handling versioning on the existing wiki, and any problems that we currently have involving multiple versions are going to be magnified for boost.

boost is copyrighted (?): We have to check any possible licensing issues, especially if we're interested in importing any of the existing boost tutorials or reference material.

If we can find satisfactory answers to those issues, I think we could start building a boost section similar to /w/c and /w/cpp. --Nate 11:22, 1 January 2013 (PST)

A couple of thoughts:

1) IMO it's hardly possible to cover all boost libraries in the foreseeable future unless there's a lot of new contributors. A possible solution would be to allow all contributions, but only show the libraries in the main page once the documentation is actually useful -- i.e. sufficiently documents most popular functionality, etc.

2) This problem will be hard to solve. An additional problem is that boost is not backwards compatible in quite a lot of cases. Some libraries have had major overhauls and it's hardly possible to document them without completely separating the documentation for each version of the library.

3) Most of the documentation is distributed under Boost software license, which is a BSD-like license -- we can do anything we want if we include the copyright text somewhere. A note on the main page of each library should be sufficient.

Unfortunately this means that being a good educational resource is not among our objectives. It is assumed that the reader has good knowledge of C and/or C++. As a consequence, a lot of things, e.g. tutorials, comments about usage cases of one feature or another, detailed explanations of things that are implicitly clear to an experienced programmer, etc., are not included and should not be added. Basically, we try to keep things simple and clear for a programmer looking for reference of a feature he already knows.

When I wrote this some time ago I wanted to prevent the mess that appeared in some pages of the old Dokuwiki based cppreference.com website. It seems that there's little chance for that happening now, so I've relaxed the above guideline. P12 10:17, 2 January 2013 (PST)

I think, maybe it is a good idea sometimes add a link to the c++ standard ISO/IEC 14882?
Like this: 8.3.6 Default arguments (1-2,4) or like this [dcl.fct.default](1-2,4).
Ruslo 00:09, 19 August 2013 (PDT)

This could be an useful bit of information. We could list all sections of the standard(s) the information of a particular page is derived from. It could be put into the references section, for example:

Note, that adding this information on all pages is a lot of work, thus I'm unsure whether this initiative is worth pursuing until there's a volunteer willing to spend some time adding this information to a major part of the wiki (say 1000 pages out of ~3000 total, this would take ~10-15 hours). P12 05:56, 19 August 2013 (PDT)

Yes, I argee. It's a lot of work, but I think it's not the main goal. Like examples - hack something, if you feel it can be improved and save it (to others and to youself). The goal is not to lose some link searching work. Ruslo 07:10, 19 August 2013 (PDT)

Second version is looks very nice and solve versioning problem. Ruslo 07:10, 19 August 2013 (PDT)

I think references (and </references>) sections are a good thing. As a formerly active Wikipedia editor, I would even enjoy seeing proper citation templates in use ( like http://en.wikipedia.org/wiki/Category:Citation_Style_1_templates ). It's true that it would be boring to go over all (or even the most popular thousand) of the existing pages, but if there is a standard way to do it, I, for one, would add a reference section whenever I edit a page.. --Cubbi 06:24, 19 August 2013 (PDT)

I like it, assuming:

...it's not too much work to create a ref template.

...it's placed at the bottom of pages, because (a) that's where references typically are found and (b) casual users of the site are probably more interested in the API and examples.

...we can come up with a way of specifying references that isn't too complicated. I like the ref template proposed above. Cubbi, can you give an example of what "proper citation templates" might look like? --Nate 07:41, 19 August 2013 (PDT)

I meant like {{cite ISO|number=14882|year=2011|title=|sectionname= |section=|paragraph=}}, which could be used with other standard documents referenced: ISO 9599, 10646, 10967, 60559, Ecma 262, and which could then be wrapped in <ref> tags to mark specific sentences and to pop up in </references> (which is already supported here). --Cubbi 08:27, 19 August 2013 (PDT)

So the {{ref}} template could generate <ref>-based output, which could be displayed in a references section using </references>? Do you think that the built-in references stuff that mediawiki has would allow us to selectively display references for C++98, C++11, etc.? (Eventually it would be neat to have a javascript-based drop-down menu that selects what standard version a given page displays.) --Nate 13:22, 19 August 2013 (PDT)

Selective display and renumbering of references would be doable even with <ref> based system. However, I'd prefer a simple text/template approach -- this way only the end of the page source would contain reference definitions and the main text would not be cluttered. This is especially useful on templated pages, since e.g. Template:cpp/container/insert would need to use {{#switch: and describe different sections of the standard for different containers. Also, we're not Wikipedia, it's probably not very useful to put a citation near each sentence or paragraph -- most of the pages here are quite short and describe a very specific subject, thus it's usually obvious which citation is for which paragraph. The exception is, of course, the description of C and C++ languages (cpp/language/*) -- <ref> is useful there.

By the way, {{cite ISO|number=14882|year=2011|title=|sectionname= |section=|paragraph=}} could be short-circuited to something like {{cite std c++11|title=|sectionname=|section=|paragraph=}} as it's hard to remember the exact ISO standard number. Proper templates could be used for the rest of references.

Okay, after giving it a bit more thought, I do agree that overwhelming majority of pages on this wiki have just one source (with versions that some day could become user-preferences/tabs), so general-purpose wikipedia approach isn't suitable. --Cubbi 07:01, 20 August 2013 (PDT)

FYI I've created the templates for the references section. Documentation is here. --P12 12:28, 23 September 2013 (PDT)

There seems to be a bug in where if I enter in a macro definition, say for example:

Run this code

#define size mysize

In a few seconds the compiler will change it to this

Run this code

# Define you in mysiz

I've only found it to be doing this when I enter in size as the macro name and use a 6-letter alphabetic definition like the above. Try it yourself and you will see.

I'm not sure how to reproduce this. When I run your first example, all I get is a bunch of linker errors complaining about a missing main function -- but the #define remains intact. When I add a main, it compiles and runs without modifying main. Did you see this behavior with a specific compiler? --Nate (talk) 06:48, 14 April 2014 (PDT)

[edit] Which revision of the C Standard does this reference adhere to?

Since you request in the FAQ that differences between C89, C99 and C11 should be marked as such, would it be worthwhile to mention that n1256 describes C99 and that n???? describes C89? Newatthis (talk) 11:55, 15 July 2014 (PDT)

It is worth mentioning that n1256 is a freely-available final draft of ISO/IEC 9899:1999/Cor.3:2007(E), which was the last revision of C99 (see History of C for the list of major and minor revisions of C). The final draft for C89 was X3J11/90-013 (ANSI numbering) or n119 (WG14 numbering), although I am not sure if it can be found for free. --Cubbi (talk) 16:18, 15 July 2014 (PDT)

I inserted a link to n1256 and included the doc numbers for C89. At iso.org, I found ISO/IEC 9899 entries listed among the withdrawn documents. Newatthis (talk) 07:17, 16 July 2014 (PDT)