Thread: Function Pointer Typedef with Same Type Arguments

In declaring a typedef for a function pointer, the format is as follows:

Code:

typedef ReturnType (*NewTypeName)(arguments...);

In your declaration, you're using the same type name for the return type and the typedef name.

The intent is to pseudo forward declare a function pointer type that will resolve to the same type as FuncPtr in the hopes that the return types of FuncPtr will be identical.

O_o

You can't have a normal function in C/C++ which returns self or similar.

The intermediate steps--two functions returning each other--you are using is just hiding the problem.

Even if you could "pseudo-forward" the pointer, the type wouldn't be resolved until use leaving you trying to return an incompatible pointer.

In other words, the type returned would conceptually change as the real definition is encountered by the compiler.

I'd say that the simplicity of the `typedef' is also hiding the problem; the signature only looks so similar because the `typedef' looks so similar.

Code:

void DoSomething1(){}

void (*DoSomething2())(){return(DoSomething1);}

void (*(*DoSomething3())())(){return(DoSomething2);}

void (*(*(*DoSomething4())())())(){return(DoSomething3);}

If I wanted to use an extra level of indirection there are some cuter solutions such as replacing FuncPtr with a class and putting my recursive function type as a member function (method ) of that class.

If you were going to use a class with specific member functions, why wouldn't you store the state for the next call?

If any of you C++ geniuses have something more efficient I'd love to see it.

You would need to use a class or similar, but you don't have to have a class with specific member functions as the type returned can be normalized despite the different signatures because the actual result can be temporarily erased. The idiomatic approach is your best bet given the current context, but I imagine that someone could offer a better solution if you told us what you were trying to do instead of just how you are trying to do it.

I've included a variation on the theme, but you should strongly consider explaining what you are trying to accomplish.

For the sake of information, you'll find the example easier to extend and make safe with C++11 features.

Soma

Code:

struct SWrapper
{
    typedef SWrapper (*RCallback)(int);
    SWrapper
    (
        RCallback fCallback
    ):
        mCallback(fCallback)
    {
    }
    operator RCallback()
    {
        return(mCallback);
    }
    RCallback mCallback;
};

#include <iostream>

SWrapper DoSomethingA
(
    int fWhatever
);

SWrapper DoSomethingB
(
    int fWhatever
);

int main()
{
    typedef SWrapper (*S)(int);
    S s(DoSomethingA(0));
    s = s(1);
    s = s(2);
    s = s(3);
    s = s(4);
}

SWrapper DoSomethingA
(
    int fWhatever
)
{
    std::cout << "A: " << fWhatever << '\n';
    return(DoSomethingB);
}

SWrapper DoSomethingB
(
    int fWhatever
)
{
    std::cout << "B: " << fWhatever << '\n';
    return(DoSomethingA);
}

OK that's interesting. So C++11 allows for arbitrary operator declarations? It's late so maybe I'm reading that wrong.

What I'm trying to do is to facilitate the calling of a compiled array of function pointers that represents a "subroutine" in my toy application specific interpreter. The basic interpreter code would look something like this,

Code:

class FlipState ;
typedef void * (*FuncPtr) (FlipState *fs, void * P) ;

void * mycall(FlipState *fs, void *next) {
FuncPtr fp = (FuncPtr) next ;
while (fp) {
  fp =(FuncPtr) (fp)(fs, (void *) (fp+1)) ;
}
void *pnext = fs->pop() /* pops the return stack of the parent */
return(pnext) ;
}

I haven't fully checked the syntax. But this represents an efficient way to call an array of functions of the same type under the condition that the calling ABI is some type of fastcall that uses registers for parameters, and that I have good locality of reference for the code and the function pointers that point to the code.

If I start burying the function pointers through additional indirection I lose performance through unnecessary memory accesses. Yes performance is why I'm using C/C++ so it's important to me.

Perhaps a good compiler would remap those indirections to registers, but this actually guarantees it for the fast call ABI interface. There is a hit in that I have to maintain my own return stack, but that's unavoidable and presumably much rarer than just executing the next sequential statement.

Also notice all the unpleasant error prone typecasting, due to the function pointer type declaration limitation. Also note that I pass the proposed return value and allow it to be modified for simulating control instructions in my interpreter. Normally you leave it alone, but if you need to jump the return value gets modified.