2019年4月10日星期三

c++ get member function's address

There exists a syntax to get the address of the member function in MSVC (starting from MSVC 2005 IMHO). But it's pretty tricky. Moreover, the obtained pointer is impossible to cast to other pointer type by conventional means. Though there exists a way to do this nevertheless.
Here's the example:
// class declaration
class MyClass
{
public:
    void Func();
    void Func(int a, int b);
};

// get the pointer to the member function
void (__thiscall MyClass::* pFunc)(int, int) = &MyClass::Func;

// naive pointer cast
void* pPtr = (void*) pFunc; // oops! this doesn't compile!

// another try
void* pPtr = reinterpret_cast<void*>(pFunc); // Damn! Still doesn't compile (why?!)

// tricky cast
void* pPtr = (void*&) pFunc; // this works
The fact that conventional cast doesn't work, even with reinterpret_cast probably means that MS doesn't recommend this casting very strongly.
Nevertheless you may do this. Of course this is all implementation-dependent, you must know the appropriate calling convention to do the thunking + have appropriate assembler skills.


or



4
try this. should let you cast anything to anything :)
template<typename OUT, typename IN>
OUT ForceCast( IN in )
{
    union
    {
        IN  in;
        OUT out;
    }
    u = { in };

    return u.out;
};
then
void* member_address = ForceCast<void*>(&SomeClass::SomeMethod);

2019年4月9日星期二

qt

The system might have different meta packages that handle the default. For example on Debian there is a qt4-default and a qt5-default package, installing one of them will uninstall the other and set the symlinks appropriately

Remote Window Managers

Remote Window Managers


Lots of times it's extremely frustrating or time consuming to run an xterm on a remote host just to fork your programs from that remote machine. Why not just run your window manager there even though you're not on its console? The window manager is just another X application, after all, isn't it?
Fire off your local X server
xinit /usr/bin/xterm -- :1 &
yields a vanilla X session with merely an xterm running - no window manager. Now you need to add permissions to this window session for the remote host. You can tunnel the connection through SSH if your network is insecure but there's a distinct performance hit. If your network is secure, you can just "xhost +remotehost" and spray directly to your X server:
Tunneled SSH:
ssh -fY remotehost /usr/bin/wmaker
or spray directly:
xhost +remotehost
ssh -f remotehost /usr/bin/wmaker -display localmachine:1
The first option, if your remote SSH server supports it, will use a locally defined DISPLAY that then gets tunneled to your local side over SSH. The second option allows remotehost to send X data directly to your local display, then runs WindowMaker there but displaying it locally. Now all your desktop actions are done on the remote machine, not locally.
Our special thanks to Bill from Washington state for this tech tip.