Talk:cpp/header

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)

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

std namespace

Two confusions for me:

1. Where on the site do we state that all the C++ headers put all the documented names into the std namespace? Is that always true? This page says that deprecated C headers act as if all the names had been placed in the global namespace - should it also state that the C++ versions put all their names in std? Pages for individual headers and libraries seem to feature a mixture - sometimes std:: is shown and sometimes not.
2. The gcc / glibc implementation seems to frequently do both: it includes the C header which puts names in the global namespace and then it lifts them into std with using or similar. Hence int32_t and std::int32_t feel interchangeable in that implementation. I am unclear on whether that's required by the standard, a technical violation of the standard, or neither.

is it allowed, but not requires by the standard. There was a recent LWG issue that clarified that allowance further (allowing the C++-specific overloads of the C library functions from the cxxx headers to show up in the global namespace even though they don't appear in the xxx.h headers). I don't think there's a place where we say that, and I think this page is probably the best place. --Cubbi (talk) 19:17, 19 January 2016 (PST)

Which C standard are the C headers in C++(03,11,17) based on?

I've been looking on cppreference for this information and can't find it anywhere, which is surprising since cppreference is usually very complete. Where would be a good place to stick this information? (and what is the answer?)

I think the answer is "C++03 based on C90; C++11 based on C99; C++14 and C++17 still based on C99", but I'm not sure if C11 might have crept in there somewhere, or even if C99 (e.g. `std::snprintf`) might have come post-C++11. --98.210.175.66 12:08, 18 April 2017 (PDT)

There is no simple answer: C++14 had something crept in from C11 (the removal of std::gets), C++17's standard library officially includes the C11's standard library (which is why we have std::timespec_get and std::aligned_alloc), but it also doesn't include C11's threads, atomics, complex number math, imaginary number math, tgmath, etc. Speaking of math, C++'s cmath is a lot bigger than C11's math.h. cppreference has been specifying the C++ standard library functions such as std::snprintf on their own right, even if each C++ standard revision defines it by referring to some revision of the C standard. We do the same thing with other standards that are included in the C++ standard by reference (IEEE-754, LIA-1, Unicode, ECMAScript). --Cubbi (talk) 12:54, 18 April 2017 (PDT)

about<codecvt>and<charconv>

all classes and enum in <codecvt> is deprecated in C++17,shall we mask it "(deprecated in C++17)"?(I masked,but you can remove the mask if you don't agree with me) <charconv>seems invaild(std::from_chars and std::to_chars is in <utility> since C++17),what should we do on it?--Yaossg (talk) 07:13, 23 August 2017 (PDT)

from_chars/to_chars were in <utility> as initially published in C++17, but that was a defect, corrected in Toronto (and, rare for library defect reports, applies retroactively - at least that's how vendors seem to take it). The <codecvt> header is indeed deprecated in [depr.locale.stdcvt]p1 --Cubbi (talk) 07:28, 23 August 2017 (PDT)

Maybe typo in description of <iomanip> header

Current description of iomanip header is

> Helper functions to control the format or input and output

Maybe there should be "of" instead of "or"? Dima (talk) 09:06, 30 January 2018 (PST)