Thread: Class function pointers

Yes that works and I've used it before but the typical misuse would be this:


B MyB;

A MyA=B.GetA();

If you make the A* a protected member of a member functor in B, I don't think you should ever run into something like that. I suppose this involves 2 function calls anyway, but I'm not entirely sure what your goal is in eliminating the first call (admittedly, I didn't read through the first page of the thread) - if you just want something that can be used like a function pointer (i.e. changed to point to different member functions in A), then this should work fine. On the other hand, if you're trying to optimize here then I suppose it isn't the greatest solution.

**EDIT**
I see now that this isn't what you want (the point of this is for optimization, right?). You can inline the operator() of the functor, but then it's equivalent (and worse) to creating intermediate inline functions as members of B.

If you're going the inlining route and you're using MSVC, then I believe there's a __forceline directive (or something to that effect) that you can use to ensure inlining wherever possible - to take some of the 'guesswork' out of whether inlining will occur or not.

2)Assign the address of the function in A to the function pointer

You can't.

Each function has a prolog and epilog like __thiscall and __stdcall, __cdecl, __fastcall etc. If you declare the function inside of the class no matter if it is a function pointer or not, it seems that is uses __thiscall. You cannot cast this away because it is saying you need an object of some type to call this function with.

The functions in A are not private, the instance of A in B is protected, therefore it doesn't matter if A's functions are public or not...you cannot get to the instance of A in B from outside of B. I do not want to return the instance of A in B - essentially I need to limit certain functions. But there is a better way and the inline method is where I'm headed as well. Also will make vital functions protected so that even if you have a copy of A, you still cannot call those functions unless you are in A or a derivation of A.

The prolog/epilog for __stdcall would be something like this (I think)

Code:

@MyFunc:
  push  ebp
  mov   esp,ebp

  ...

  pop ebp

Read the compiler docs as each one is explained including who is responsible for cleaning up the stack.
The reason I could do this in assembly is because most of C++ is compiler-side rules, that is they are only in effect inside of the compiler. Once the object code has been written, I can still gain access to anything I want from pure asm code. However, this is not a good practice and I won't get into manually editing my C++ code.

The __pascal modifier means that parameters are pushed from right to left and the __cdecl means they are pushed from right to left (or vice versa I forget).

So if you have a function like so in 32-bit code:

unsigned int Subtract(unsigned int v1,unsigned int v2)

To call this:

Code:

  push [v2]
  push [v1]
  call Subtract

  Subtract:
    push  ebp
    mov ebp,esp

    mov  eax,[ebp+12]
    sub   eax,[ebp+8]
    
    pop   ebp

Which is far different from:

Code:

  push [v1]
  push [v2]
  call Subtract

  Subtract:
    push  ebp
    mov ebp,esp

    mov  eax,[ebp+12]
    sub   eax,[ebp+8]
    
    pop   ebp

The two will yield very different results. And this is of course barring the fact that name mangling will occur with C++, unless you explicity tell it not to mangle them.

Sorry, I don't understand much of that. Here is my latest attempt--I have no idea if it is optimized the way you want--but it keeps users from being able to get at AInstance inside the Object class:

Code:

#include<iostream>
using namespace std;

class A
{
  public:
    void Func(int x) {cout<<x<<endl;}
};

class Object
{
    A AInstance;
    void (A::*pFunc)(int);
   
public:
     
    Object(void)
    {
        pFunc = &A::Func;
    }
    
    void operator()(int x)
    {
        (AInstance.*pFunc)(x);
    }
};




int main()
{
    Object o;
    o(3);
    
    return 0;
}

This method goes the inlined-intermediate route as well, except that it adds an extra indirection by calling A's member function through a function pointer.. it's unsuitable for the same reason as my functor idea

OK, I'm just here to clear up some confusion about calling conventions.
The keywords MSVC supports are __cdecl, __stdcall and __fastcall.
In addition, error messages may contain the __thiscall "keyword", but its use is not valid in code.

So what are they about?
The first three dictate how parameter handling happens on the function call.
The fourth, thiscall, merely indicates that the function is a member function and should receive the additional this pointer as parameter. This convention is not mutually exclusive with the others; in fact, every COM method is a __thiscall __stdcall.

__cdecl:
The standard C convention dictates that parameters are pushed on the stack from right to left. The caller is responsible for cleaning up the stack; this means that the caller can push as many arguments as he wants. Only this convention allows variable argument lists.
The standard C name mangling prefixes the function name with an underscore.

__stdcall:
The Pascal convention dictates that parameters are pushed on the stack from left to right. The callee is responsible for cleaning up the stack by means of the parametrized ret instruction; as such, passing variable argument lists is not possible, given that the callee has no way of knowing how much was really passed.
The standard C name mangling under this convention prefixes the function name with an underscore, and in addition appends an @-sign followed by the number of bytes that the function expects in its parameter list.

__fastcall:
This is essentially the same as __stdcall, but with some rules as to how some parameters are passed in registers instead.


__thiscall merely adds an additional hidden parameter. I believe it always adds it as the left-most one, meaning that it would be at ebp+4 under __cdecl, but ebp+(bytes in declared parameter list)+4 under __stdcall.

In addition, error messages may contain the __thiscall "keyword", but its use is not valid in code.

Yet.

Seems that future plans may incorporate this into the next generation of compilers. The error message I get is that __fastcall is a reserved future symbol.

But CornedBee hit the nail on the head. I don't do much assembly anymore so my knowledge of declarations in C and what they do were a bit rusty and for that I do apologize...but I did warn ya.

Most 32-bit programs start parameter lists at ebp+8. At ebp+0 is the previous value of ebp, ebp+4 is the return address of the caller, ebp+8 is the first function parameter. But this can be changed by using the above declarations and the order in which parameters are pushed can also be changed.

But what CornedBee said about __thiscall is exactly why my function pointers are not working. And since the language was not intended to directly support what I'm doing....then I'm doing it wrong.

I will change my structure and setup to work with the language instead of against it.

Seems that future plans may incorporate this into the next generation of compilers.

I don't see what the use would be. A global/static function is a global/static function and a member function is a member function. Member functions are __thiscall and global/static functions are not. End of story, for me.