New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
consider whether [cinttypes.syn] is in the right place #1997
Comments
We can try an approach similar to |
The current placement might actually be a mistake. In early drafts like http://wg21.link/N2009 the header is mentioned in clause 18.2 [lib.support.limits] "The headers 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 |
I think I would like the idea of treating this like 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.
The text was updated successfully, but these errors were encountered: