Open zygoloid opened 6 years ago
We can try an approach similar to <cstddef>
: the synopsis lives in some place, but its parts are documented in (I believe) three different parts of the Standard.
The current placement might actually be a mistake.
In early drafts like http://wg21.link/N2009 the header
"The headers <limits>
, <climits>
, <cfloat>
, and <cinttypes>
supply characteristics of implementation-dependent fundamental types (3.9.1)."
But the header synopsis surprisingly appeared at the very end of clause 27 (input/output).
When I mentioned this inconsistency on the comp.std.c++ news group, it was fixed by striking all references to the header from clause 18. I had perhaps expected the synopsis to be moved. :-)
I mean, I can see how one might have come to that conclusion. cintypes isn't about characteristics of types, but rather about how you use printf
. To that end, cinttypes includes cstdint, which is part of [support.general]. (The abs
and div
bit are weird, though.)
I think I would like the idea of treating this like <cstddef>
and distributing the detailed description... except that we don't have much in the way of detailed description for this header, just the synopsis, a pointer to the C standard, and bad overloads of std::abs
and std::div
(that should be made available by <cstdlib>
, matching what we do for all the other primitive-type overloads of std::abs
).
Hmm. We should point out to LWG that LWG 2294 / 2192 missed a spot...
Editorial meeting consensus: This is the least worst location for the header. Remaining issue: This has abs/div declarations that need to become part of the complete overload set for these functions.
<cinttypes>
is a weird header. It containsabs
anddiv
forintmax_t
, plus some primitive string \<-> integer conversion functions. And someprintf
/scanf
format string macros. And we put it in the iostreams portion of the standard.Is this really best?
We once kept all the formatting and parsing stuff within [input.output], but now we have [charconv], and somewhere near there seems like a much better fit for the primitive formatting and parsing functions in.
The integer div / abs functionality seems to belong in [numerics].
The format string macros seem to belong near [cstdio.syn], which is where the header currently is.
And maybe we could "compromise" and put the header in [cstdint].
So: I'm not sure what's best, but we should talk about it some more, especially given that the advent of [charconv] significantly weakens the argument for the current home.