Date: Sat, 12 Feb 2022 19:15:49 +0000
On Saturday, February 12th, 2022 at 10:03 AM, Mark de Wever <koraq_at_[hidden]> wrote:
>
> Note the ? in https://wg21.link/p2286R6 is a type specifier and not a
> new element of the std-format-spec. So the example should be
> std::println("at {:?}", p);
>
Yes.
> >
> > [...] I hope we can build
> > the understanding of pointers != integers
> > after http://wg21.link/p2318 (provenance-
> > aware memory object model).
>
> [...], but didn't find an example how
> printf's output for %p changes with this proposal. Do you have an
> example?
>
> The format specializations affected by this paper only format the types
> (const) void* and nullptr_t. Effectively only the formatter of
> const void* is used since that's how the pointer is stored in a
> basic_format_arg object. So the pointer has no information regarding the
> object type it points at, if any.
>
It's a problem worth solving, isn't it?
> For formatting pointers of your own types you need to provide your own
> formatter specialization. There you can implement printing the type of
> the pointer if wanted.
>
> I think your example can certainly be useful, but it's outside the scope
> of this proposal.
>
My point is that the "scope of the
proposal" isn't concentrating on
a problem worth solving. Pointers
!= integers. You can compare
integers to integers and their text
representations as specified
in std::format, but the result
may have nothing to do with the
result of comparing pointers.
There are invalid pointer values,
there are no invalid integer values.
Whether those text representations
as specified as 0x, or 0X, or not,
doesn't make <format> more useful,
IMO.
And my suggestion is, before
enabling more flags on top of the
conditionally implementation-defined
'p', think about what can be done
to make the existing specifiers
more useful. Can '?' work on
pointers? Can 'p' work on smart
pointers? What <format> can do
to function pointers and pointers
to member functions?
>
> Note the ? in https://wg21.link/p2286R6 is a type specifier and not a
> new element of the std-format-spec. So the example should be
> std::println("at {:?}", p);
>
Yes.
> >
> > [...] I hope we can build
> > the understanding of pointers != integers
> > after http://wg21.link/p2318 (provenance-
> > aware memory object model).
>
> [...], but didn't find an example how
> printf's output for %p changes with this proposal. Do you have an
> example?
>
> The format specializations affected by this paper only format the types
> (const) void* and nullptr_t. Effectively only the formatter of
> const void* is used since that's how the pointer is stored in a
> basic_format_arg object. So the pointer has no information regarding the
> object type it points at, if any.
>
It's a problem worth solving, isn't it?
> For formatting pointers of your own types you need to provide your own
> formatter specialization. There you can implement printing the type of
> the pointer if wanted.
>
> I think your example can certainly be useful, but it's outside the scope
> of this proposal.
>
My point is that the "scope of the
proposal" isn't concentrating on
a problem worth solving. Pointers
!= integers. You can compare
integers to integers and their text
representations as specified
in std::format, but the result
may have nothing to do with the
result of comparing pointers.
There are invalid pointer values,
there are no invalid integer values.
Whether those text representations
as specified as 0x, or 0X, or not,
doesn't make <format> more useful,
IMO.
And my suggestion is, before
enabling more flags on top of the
conditionally implementation-defined
'p', think about what can be done
to make the existing specifiers
more useful. Can '?' work on
pointers? Can 'p' work on smart
pointers? What <format> can do
to function pointers and pointers
to member functions?
-- Zhihao
Received on 2022-02-12 19:15:54