C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Simplify taking pointer to non-static member function

From: connor horman <chorman64_at_[hidden]>
Date: Tue, 6 Feb 2024 15:58:43 -0500
Incidentally, a general version of mem_func_wrapper exists - it's called
std::bind_front. It even works with pointers to data members (although it
just yields a constant value generator).

On Tue, Feb 6, 2024 at 15:09 Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Tue, Feb 6, 2024 at 1:44 PM ஜெய்கணேஷ் குமரன் via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> >
> > On 06-Feb-2024, at 23:40, Arthur O'Dwyer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > On Tue, Feb 6, 2024 at 12:56 PM Jason McKesson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >>
> >> On Tue, Feb 6, 2024 at 12:08 PM ஜெய்கணேஷ் குமரன்
> >> <jaiganesh.kumaran_at_[hidden]> wrote:
> >> >
> >> > If you're in a context where `function` results in a non-static,
> >> > non-overloaded member function, then `&function` will result in a
> >> > pointer to that function.
> >> >
> >> >
> >> > Unfortunately no, this does not work; you must qualify it with the
> class name.
> >> >
> >> > From cppreference:
> >> > Expressions such as &(C::f) or &f inside C's member function do not
> form pointers to member functions.
> >>
> >> Well, the three major compilers disagree:
> https://gcc.godbolt.org/z/ddMbecv84
> >> It could be bugs in all of them though. It's a pretty narrow corner
> case.
> >
> >
> > Taking the address of a static member function is fine and gives you a
> pointer-to-function.
> > The forbidden thing, which I think all compilers do correctly forbid, is
> when you take the address of a non-static member function to get a
> pointer-to-member-function:
> > https://gcc.godbolt.org/z/7KhfdEPKW
> >
> >
> >> > I want something like this:
> >> > auto f = &class_name::function;
> >> > class_name* p = f.this_ptr;
> >>
> >> That doesn't make any sense. Member pointers are not associated with
> >> any particular instance. That's kind of the point.
> >
> >
> > +1. This fundamental misunderstanding of what a "pointer to member"
> actually is, makes me think that the original feature request was
> mis-motivated too.
> > (OP wants an easier way to extract pointers-to-member-functions... but
> at the same time, OP thinks "pointer-to-member-function" means something
> more like std::bind. So maybe OP is really looking for C++11 lambda syntax?
> He's certainly not looking for pointers-to-member-functions anymore.)
> >
> >
> > No, I don't want something like bind; I just want the
> member-function-pointer-taking syntax to give me the this pointer as well
> so that it is cleaner to construct a wrapper if needed - otherwise you can
> throw it away by assigning into a regular member-function pointer variable,
> which is the same as what you get in a static context.
> >
> > mem_fn_wrapper(&class_name::function); // the wrapper should be able to
> extract both the function pointer and the this pointer of the current
> instance.
>
> There is no "this pointer of the current instance" which any
> hypothetical "mem_fn_wrapper" could possibly know about. The member
> pointer, the expression `&class_name::function` does not know what
> "this" is.
>
> Yes, a *language* feature could do that, but it wouldn't be spelled
> `&class_name::function`. You'd need some other syntax for that. Even
> if that syntax is just some new kind of type, why would you burn
> precious language syntax on something that you could do just as easily
> as do with `mem_fn_wrapper(this, &class_name::function);`?
>
> Remember: we're talking about querying information that you *already
> have*. The "this pointer of the current instance" is clearly available
> to whomever is writing `&class_name::function`. Besides your personal
> convenience, what's the point here?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2024-02-06 20:58:57