Member Function pointer can also be a vtable offset and a this adjustment.
That cannot be converted to a function pointer w/o an object to resolve the
vptr on. What do you propose happens in this case? A null pointer?
Undefined behaviour?

On Fri, 5 Jan 2024 at 08:22, Jarrad Waterloo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>