Cppreference talk:FAQ

Revision as of 18:45, 2 January 2013 by Nate (Talk | contribs)



Should we include information about TR1? -- Jaredgrubb 07:41, 2 July 2011 (PDT)

Fixed.P12 12:34, 2 July 2011 (PDT)
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)

2011 C++ Standard

ISO/IEC 14882:2011 is now published. This page shouldn't be talking of drafts. Jonathan de Boyne Pollard 02:27, 24 March 2012 (PDT)

  • The linked draft is the latest publicly downloadable --Bazzy 02:51, 24 March 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)
We should add the ANSI Store purchase link for C++11, which is 10 times cheaper than the ISO store currently linked: --Cubbi 07:49, 25 July 2012 (PDT)
Good idea -- done. --Nate 13:07, 25 July 2012 (PDT)

C Reference

This page should be updated to mention the new C reference section of the site. --- Undeterminant 10:34, 22 April 2012 (PDT)

Updated. Thanks. -- P12 10:52, 22 April 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)

Broken links

Information about broken links on this website can be reported below

There are couple of links "std::terminate_handler" on the page that points to instead of

Thanks; looks like a typo in our syntax highlighter that was just fixed: The next time we refresh, the page should be fixed. -Nate 11:25, 31 October 2012 (PDT)

Boost Documentation?

According to the FAQ:

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 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?

CStubing at EFNet 10:55, 31 December 2012 (PST)

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 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.
P12 09:50, 2 January 2013 (PST)

Too strict introduction

I think that the following text in the FAQ is overly strict.

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

Looks peachy. --Nate 17:45, 2 January 2013 (PST)