C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Allow conversion of memfunc pointers to func pointers

From: Ivan Lazaric <ivan.lazaric1_at_[hidden]>
Date: Sat, 6 Jan 2024 14:52:15 +0100
When would this be useful, and the problem at hand couldn't be solved with:
https://godbolt.org/z/65s7PePaW
I think the implementation at ^ should match behaviour described in Jarrads
paper, not sure.
Is there any observable difference between a free function version of a
member function, and
a free function that behaves identically as the aforementioned free
function?

On Sat, Jan 6, 2024 at 1:14 PM Frederick Virchanza Gotham via Std-Proposals
<std-proposals_at_[hidden]> wrote:

> On Sat, Jan 6, 2024 at 12:05 PM Frederick Virchanza Gotham wrote;
> >
> > Even though the "offset
> > for this" is lost when "std::memfunc_to_func" is invoked, it could be
> > regained when "std::invoked_func_as_memfunc" is invoked (as it can be
> > determined from the type of the 2nd parameter -- i.e. the pointer to
> > the object). This might even be an enhancement as it means the 'this'
> > pointer will be correctly adjusted no matter what object you give it
> > (i.e. you're not limited to the type that was passed to
> > 'std::memfunc_to_func').
>
>
> And therefore, even on implementations that use thunks,
> "std::memfunc_to_func" should not return the address of the thunk, but
> rather it should return the address of the bonafide function. Then
> it's the job of "std::invoke_func_as_memfunc" to adjust the 'this'
> pointer where necessary.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2024-01-06 13:52:29