Hello,
Thank you all, for your useful input, I'm sure the author appreciates it.
Few design considerations came up in the thread, so the paper will need to be discussed in a telecon before moving forward.
Paper was scheduled for LEWG telecon on 2022-05-03 (15:00 UTC).
Attaching a summary of the main issues which came up in the thread:
- The functionality was supported:
- I have had the need to format pointers in the various ways described in the paper on numerous occasions (except for locale considerations, but as an opt-in, I see no issue).
- On the other hand, there was some discussion on the necessity of the proposal:
- I have a stronger need for seeing: std::println("at {:?p}", p); // '?' is introduced in http://wg21.link/p2286.
output: at 00007ffb`a67fb331 myLib!myNs::SomeCls, Address is an identity of object in C++, so when printing an address, I want to see what is there.
Author: The format specializations affected by this paper only format the types (const) void* and nullptr_t. (...) So the pointer has no information regarding the object type it points at, if any. - For the '0' and 'P' features, I am not opposed, but also not convinced to the usability of them.
- Using the locale mechanism got some objection:
- Allowing locale-dependent printing of pointers in order to get a more readable representation seems a hack to me. If the user goal is a If the user goal is a more readable pointer representation, we should be providing a direct way to obtain it, not something that abuses the localization mechanism to achieve it indirectly.
- As an option we could remove the more "controversial" locale part. '0' and 'P' seem OK and there were some requests for the former.
- I am oposed to the paper introducing 'L' as valid specifier for pointers. Using it to get underscore is locale specific, and thus cannot be used in program that want to achieve this formatting in portable way.
- There was some discussion on the desired formatted output:
- My preferred output when printing numbers in hexadecimal is 0x05D4; that is, the base prefix is lowercase 0x, but the number itself uses uppercase A-F.
This is not a problem for numbers because I can just omit the # and add the base prefix by hand, e.g. `0x{:04X}` instead of `{:#06X}`. But since # is implicit for pointers, this isn't (going to be) possible when using the P specifier.
Suggestion: # when present will remove the base prefix, instead of adding it.
Author: Currently # isn't allowed for pointers, so I don't see compatibility or implementation issues. I'll include it in the next version of the paper. - Can 'p' work on smart pointers?
Author: There's a proposal https://wg21.link/p1636r2. But the paper hasn't been updated for a while. I'm not sure whether the author is still pursuing this. - What <format> can do to function pointers and pointers to member functions?
Author: At the moment nothing, but this is an interesting question. I'll give this some more thought and since there's no support yet it's easier to consider adding debug information support from the start. - There was a request for implementation.
Best regards,
Inbal Levi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Tuesday, February 15th, 2022 at 12:49 PM, Tomasz Kamiński via Lib-Ext <lib-ext@lists.isocpp.org> wrote:
For the '0' and 'P' features, I am not opposed, but also not convinced to the usability of them.
I think introducing any "feature"
that we already have
(reinterpret_cast<uiniptr_t> + x)
by occupying severely precious
mini-language grammar in the
standard is a waste of design
space. GCC and Clang have
been issuing warnings on %08p
for a long time. Which means,
if we want to flip the impression
of "%p has no flags," the
outcome must be useful enough
to teach. And I believe more
useful things can be done on
0 + p or P, more useful than
saving some keystrokes.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
The best way to predict the future is to invent it.