C++ Logo

std-proposals

Advanced search

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

From: Jarrad Waterloo <descender76_at_[hidden]>
Date: Fri, 5 Jan 2024 08:21:54 -0500
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2603r1.html

My motivations were 2 part.

A. Reduce the bifurcation between function pointers and member function
pointers. The lack of this functionality seems more of an
oversight/underspecification of initial standardization. This is about
completeness. Further, whenever one bifurcate it never gets rid of the need
of speaking of the two when it is non bifurcated. This happens time and
time again with other bifurcated items in C++; think universal error
handling and universal references as examples.

B. Reclaim something lost when C++ went from CFront to a standard language
of its own. In CFront, there exists a free function for every member
function. We are just asking to be able to take the address of something
that is always there.

My paper above gives small examples of its utility which can grow into
better large runtime traits/ runtime concept map utilities.


On Fri, Jan 5, 2024 at 8:00 AM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> What do you want to achieve?
>
> The shown code of course could just call
>
> m.Go(45.3);
>
> or could store a pointer to member function.
>
>
>
> Does p have the right type? Even for the 95% of implementations, it would
> need two parameters or alternatively it would need a different type than a
> 'normal' non-member function.
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Frederick Virchanza Gotham via Std-Proposals <
> std-proposals_at_[hidden]>
> *Gesendet:* Fr 05.01.2024 13:40
> *Betreff:* [std-proposals] Allow conversion of memfunc pointers to func
> pointers
> *An:* std-proposals <std-proposals_at_[hidden]>;
> *CC:* Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
> At least 95% of C++ implementations nowadays use a calling convention
> that performs the invocation of a class's member function by moving
> all the arguments down one position, and putting the 'this' pointer in
> the first position.
>
> So for example on x86_64 on Microsoft Windows, if a normal function
> takes three integer arguments, these arguments will be put in RCX,
> RDX, R8. If a member function takes three integer arguments, then
> RCX,RDX,R8 will be moved down to RDX,R8,R9 and then the 'this' pointer
> will be put in RCX.
>
> Only about 4 implementations of C++ leave the function arguments alone
> and store the 'this' pointer in another register (for a list of them,
> see page 4 of http://www.virjacode.com/papers/paper_nrvo_latest.pdf ).
>
> So anyway, what if we were able to do the following in Standard C++?
>
> struct Monkey {
> unsigned i;
> virtual unsigned Go(double x) { return i +
> static_cast<unsigned>(x + 0.5); }
> };
>
> int main(void)
> {
> Monkey m = { 8u };
>
> unsigned (*p)(double) = std::memfunc_to_func( &Monkey::Go, &m );
>
> std::invoke_func_as_memfunc(p, &m, 45.3);
> }
>
> The function 'memfunc_to_func' would take two arguments:
> (1) A pointer to a member function for class T
> (2) A pointer to an object of type T
>
> It needs the second argument just in case the member function is
> virtual and it needs to look at the vtable of the supplied object.
>
> The function 'invoke_fun_as_memfunc' takes two or more arguments:
> (1) A normal function pointer which holds the address of a member
> function
> (2) An address of an object
> (3) Any arguments to be passed to the member function
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

Received on 2024-01-05 13:22:06