Date: Mon, 14 Feb 2022 21:20:22 +0100
On Sat, Feb 12, 2022 at 07:15:49PM +0000, Zhihao Yuan wrote:
> On Saturday, February 12th, 2022 at 10:03 AM, Mark de Wever <koraq_at_[hidden]> wrote:
> > 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?
Yes.
> > 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?
Implementing '?' on pointers seems non trivial and I'm not even sure
whether it can be done without compiler support. Even when getting
compiler support I directly see some issues.
What type to print when a library, not part of your application, returns
a 'void *'? The type is probably a type private to the library and it's
not possible know the real type it's pointing at.
What is the type of a pointer that points one beyond an array? Is it the
type of the elements of the array? Is it an invalid type?
This pointer has another issue; at the same memory address can be a
valid object, that happens to be placed directly beyond the array. When
std::format gets a void pointer, how can it solve the ambiguity of these
to possible types.
It would be great when somebody solves this problem, but I don't feel
qualified to solve that problem.
IMO both these problems are worth solving.
> Can 'p' work on smart pointers?
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?
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.
Cheers,
Mark
> On Saturday, February 12th, 2022 at 10:03 AM, Mark de Wever <koraq_at_[hidden]> wrote:
> > 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?
Yes.
> > 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?
Implementing '?' on pointers seems non trivial and I'm not even sure
whether it can be done without compiler support. Even when getting
compiler support I directly see some issues.
What type to print when a library, not part of your application, returns
a 'void *'? The type is probably a type private to the library and it's
not possible know the real type it's pointing at.
What is the type of a pointer that points one beyond an array? Is it the
type of the elements of the array? Is it an invalid type?
This pointer has another issue; at the same memory address can be a
valid object, that happens to be placed directly beyond the array. When
std::format gets a void pointer, how can it solve the ambiguity of these
to possible types.
It would be great when somebody solves this problem, but I don't feel
qualified to solve that problem.
IMO both these problems are worth solving.
> Can 'p' work on smart pointers?
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?
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.
Cheers,
Mark
Received on 2022-02-14 20:20:26