Date: Sun, 8 Jan 2023 23:16:33 +0100
On 08/01/2023 22.35, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Sun, Jan 8, 2023 at 7:34 PM Jason McKesson via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> But... that's not what you were asked for. You were asked why this
>> feature needs to exist. What the motivation is, beyond merely
>> "pointers to pointers are a thing, so there should be a mechanism to
>> fully dereference them down to the first non-pointer type". Why is
>> this something that needs to be in the standard, when common C++
>> idioms and advice are to avoid raw pointers as much as possible?
>
>
> You mention raw pointers, but 'xdref' works with 'std::unique_ptr' and
> also things like 'std::optional' -- it works with anything that can be
> dereferenced.
>
> I might add code to 'xdref' to check if the type is an 'std::optional'
> and to throw an exception if 'has_value()" returns false.
>
> Sometimes an idea comes to me to develop a solution before I've
> discovered the problem. Ideas are coming to me now that I've got
> 'xdref' written. Like if I have a template function that iterates
> through the elements in a container, then for efficiency I can sort a
> container of pointers to the elements, but my original template
> function can deal with the container of pointers just as though it
> were dealing with a container of T's. Similarly a template function
> can deal with std::optional<T> instead of just plain T. Or a template
> function can deal with std::unique_pointer< std::optional<T> > instead
> of just plain T.
Well, you're welcome to write all kinds of interesting function
templates for your own purposes or publish them as a library as
you see fit. However, this is the std-proposals mailing list,
where proposals for future evolution of the ISO standard for C++
are being discussed. In order for a proposal to be viable,
rationale must be presented why a proposed feature provides
a net benefit over its costs. So far, I'm not even seeing a
reasonable analysis of either in this discussion.
> Two examples:
>
> template<typename T>
> void IncrementEverything(T &container)
> {
> for ( auto &e : container )
> {
> ++xdref(e);
> }
> }
What if my "payload" data is actually pointers,
and I want to perform pointer arithmetic on those
pointers instead of incrementing the eventual
dereferenced non-pointer value? It seems a lot
more plausible to be cognizant of the number of
levels of pointer indirection when writing such
(generic) code instead of blindly dereferencing
to the max.
Note that the std::ranges-enabled algorithm variants
support projections to help with some of this.
> template<typename T>
> void RecordEntry(std::ostream &os, T &&obj)
> {
> std::time_t const result = std::time(nullptr);
> os << "Recorded at " << std::ctime(&result) << xdref(obj) << std::endl;
> }
>
> Basically you can write a template function and think "I don't care
> how many levels of indirection there are, I wanted the root object",
What if the root object happens to be a pointer, for my view
of "root"?
> and it there's no object in existence then there'll be an exception
> thrown rather than a segfault.
Jens
> On Sun, Jan 8, 2023 at 7:34 PM Jason McKesson via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> But... that's not what you were asked for. You were asked why this
>> feature needs to exist. What the motivation is, beyond merely
>> "pointers to pointers are a thing, so there should be a mechanism to
>> fully dereference them down to the first non-pointer type". Why is
>> this something that needs to be in the standard, when common C++
>> idioms and advice are to avoid raw pointers as much as possible?
>
>
> You mention raw pointers, but 'xdref' works with 'std::unique_ptr' and
> also things like 'std::optional' -- it works with anything that can be
> dereferenced.
>
> I might add code to 'xdref' to check if the type is an 'std::optional'
> and to throw an exception if 'has_value()" returns false.
>
> Sometimes an idea comes to me to develop a solution before I've
> discovered the problem. Ideas are coming to me now that I've got
> 'xdref' written. Like if I have a template function that iterates
> through the elements in a container, then for efficiency I can sort a
> container of pointers to the elements, but my original template
> function can deal with the container of pointers just as though it
> were dealing with a container of T's. Similarly a template function
> can deal with std::optional<T> instead of just plain T. Or a template
> function can deal with std::unique_pointer< std::optional<T> > instead
> of just plain T.
Well, you're welcome to write all kinds of interesting function
templates for your own purposes or publish them as a library as
you see fit. However, this is the std-proposals mailing list,
where proposals for future evolution of the ISO standard for C++
are being discussed. In order for a proposal to be viable,
rationale must be presented why a proposed feature provides
a net benefit over its costs. So far, I'm not even seeing a
reasonable analysis of either in this discussion.
> Two examples:
>
> template<typename T>
> void IncrementEverything(T &container)
> {
> for ( auto &e : container )
> {
> ++xdref(e);
> }
> }
What if my "payload" data is actually pointers,
and I want to perform pointer arithmetic on those
pointers instead of incrementing the eventual
dereferenced non-pointer value? It seems a lot
more plausible to be cognizant of the number of
levels of pointer indirection when writing such
(generic) code instead of blindly dereferencing
to the max.
Note that the std::ranges-enabled algorithm variants
support projections to help with some of this.
> template<typename T>
> void RecordEntry(std::ostream &os, T &&obj)
> {
> std::time_t const result = std::time(nullptr);
> os << "Recorded at " << std::ctime(&result) << xdref(obj) << std::endl;
> }
>
> Basically you can write a template function and think "I don't care
> how many levels of indirection there are, I wanted the root object",
What if the root object happens to be a pointer, for my view
of "root"?
> and it there's no object in existence then there'll be an exception
> thrown rather than a segfault.
Jens
Received on 2023-01-08 22:16:36