Question

Inside of a static member function I need to get the type.

class MyClass
{
     public:
         static void myStaticFunc();
     ...
};

And then in the implementation I want to have:

void MyClass::myStaticFunc()
{
     // Get MyClass as a type so I can cast using it
     (get_type_from_static_function()*)someOtherVariable;
}

Is this even possible? Normally I would use something from typeinfo on an object but I don’t have this to work with.

I do not want to just use (MyClass*) because this is going inside of a macro and I’d like to keep it as simple as possible so that it can be called without a class name.

If it helps I am using QT but I couldn’t find any macros to get the current class. It doesn’t necessarily need to be programmatic – it can be a macro.

Cheers!

EDIT:
Here is the actual macro function:

#define RPC_FUNCTION(funcName) \
static void rpc_##funcName(void* oOwner, RpcManager::RpcParamsContainer params){ ((__class__*)oOwner)->funcName(params); }; \
void funcName(RpcManager::RpcParamsContainer params);

I then call RPC_FUNCTION(foo) in a class declaration. I want __class__ to be whatever class declaration I am in. I’m well aware I can just add className after funcName but I want to keep this as simple as possible when actually using it. My RPC manager calls rpc_foo and passes a pointer to an object of the class I declared it in. Essentially I need to know how to determine the actual class of that void* parameter.

Answer 1

I believe that what you’re asking for at heart is simply not possible: C++ is a statically typed language, which means that all type information must be available at compile time (runtime polymorphism notwithstanding). That is, when you say,

T x;

then the type T must be known at compile time. There is no such thing as “T_from_user() x;“, whereby the actual type of a variable is determined at runtime. The language just isn’t designed that way.

Usually if you’re asking such a question that’s an indicator that you’re going about a problem the wrong way, though. Typical solutions for polymorphic situations involve class inheritance and virtual functions, or other sorts of lookup tables, or really any number of different approaches. Your request for a preprocessor macro also indicates that something is off. Any programming language has its idioms, and veering too far from those is usually a bad idea.