Who decides what headers are part of what "libraries"?

In other documentation I have seen a header as being alternately in utility, general, language support or other "libraries".

I suggest that <cfloat>, <limits> and <climits> could be considered part of the "numerics" library as the are "general".

Also, I grouped related libraries (e.g. strings and regular expressions) together and added an extra blank line between some groupings to emphasize the grouping. Arbalest 07:12, 17 February 2012 (PST)

Generally, for the wiki as a whole, we tried to stick to the standard, except for several exceptions where we thought that it's reasonable to depart. IIRC the exceptions are that we merged $18 Language support library, $19 Diagnostics library, $20 General utilities library into one Utilities library, since they weren't categorized well in the standard. E.g. error management was covered in both Diagnostics library and Language support library (section Exception handling). Also, we moved ratio to numerics, because it fits there much better than in general utilities.
Here I think a good idea would be to group the headers in the same way as in the rest of the wiki, because it would be easier to find features. Also, I think decomposing the tables into lists would look better. E.g.
  • <header> - contains ...
P12 02:46, 17 February 2012 (PST)

This is going to be a problem as the standard "libraries" to not correlate 1-to-1 with headers (i.e., a header can contain parts of more than one "library" and a library can be made up of more than one header).
If this section is about Headers (per the title) then they should occur once and indicate which libraries they "support" (as there will be more than one) as well as what they contain. If the section is really about the standard's "libraries" then multiple headers will make up each library with some headers also showing up in multiple libraries. The problem with this choice, as noted above, is that the standard includes headers in what sometimes seems arbitrary libraries.
What is the best way to do this that looks clean and is much more convenient than looking at the spec or the headers themselves? Arbalest 10:19, 17 February 2012 (PST)
Well, here are the offenders: <cstdlib> shows up in Language Support, General Utilities, Strings, Algorithms and Numerics. And, <ctime> is in Language Support and General Utilities. Combining libraries as mentioned above takes care of <ctime> and part of <cstdlib>. We can put <cstdlib> in the combined Utilities section (and not in the others) and call it a day. Arbalest 11:34, 17 February 2012 (PST)
The issues with the headers was one of the reasons why we didn't consult them when categorizing content. They themselves actually are not very important, since the really relevant stuff is within them, the headers are only containers. So we might have less than ideal categorization here. One of the options would be to categorize the headers in the same way as in the wiki: that would be more intuitive, also a lot of problems are already solved there. I've reordered the headers in this way - see if you like it. Now the mess seems to be contained only within the Utilities library and <cstdlib>. P12 13:52, 17 February 2012 (PST)
I think it is OK this way. My only concern is that the heading text styling somewhat hides the idea that the Utilities Library has subsections -- versus those being top level sections on their own. Also, the headers and their arrangement are kind of important to me even if not important to the bigger picture. I use the list and groupings to get a sense of coverage/completeness to my understanding of the whole library.Arbalest 09:29, 21 February 2012 (PST)
I didn't say that headers are totally unimportant, just that the content deserves a bit more attention. In the future we may have listing of all declarations within each header with links to the pages in the wiki describing them. P12 09:50, 21 February 2012 (PST)

[edit] One page for each header

I think it may be helpful to have a page for every standard header. I mean very simple pages, containing just the links to relevant pages describing the symbols defined in that header, pretty much like the cpp/keyword/* pages.

This can then be reflected in the search page.

Is this a good idea or just a waste of time?

--Bazzy 08:39, 5 December 2012 (PST)

I think it could be useful. I like the ability to connect information both ways: if you can find a header from a function, you should be able to find the function from the header. --Cubbi 10:48, 5 December 2012 (PST)
I've created an example at cpp/header/string --Bazzy 11:39, 5 December 2012 (PST)
IMO a good option would be not just post the links to the relevant functionality, but provide full declarations like in the synopses of headers in the standard. The links would be added automatically. P12 14:11, 5 December 2012 (PST)
I agree, can this be done nicely with the current list templates? --Bazzy 01:31, 6 December 2012 (PST)
It is possible to append a ddcl list item section below each description template. Though I think we can skip the descriptions altogether and just put a huge {{source}} block with declarations of each class or function. P12 05:59, 6 December 2012 (PST)
Pasting the synopsis verbatim from the standard in a {{source}} won't work with automatic linking. Prepending each symbol with std:: will work only for classes and functions, not for operators or macros. Maybe the ddcl option is the best, that also has the benefit that can be pasted from existing pages.
(Edit) The ddcl has still issues with operators. What about having the dcl list to provide links and the source to provide the synospis?
--Bazzy 06:22, 6 December 2012 (PST)
Indeed, I forgot that std:: is mandatory. I agree, let's do as you propose. P12 07:06, 6 December 2012 (PST)
+1 This is a great idea, Bazzy. -Nate 12:22, 6 December 2012 (PST)
I wonder if we could modify ddcl_list_header so that it automatically links to the appropriate header. Seems like it might be useful to have e.g. "Defined in header <vector>" actually link to the header... - 05:39, 7 December 2012 (PST)
Let's wait a bit until we have all header pages created. P12 08:08, 7 December 2012 (PST)