Thread: member fn pointer -> fn pointer?

Originally Posted by pheres

for example the api of the sort algorithm is not designed to accept a member pointer. but there are adapters to make it work (whats what I found out while reading about that things). so cats work at least together with dogs. why stop at this point?

That's because the sort algorithm's comparator is a template parameter. It can be ANY kind of object, not just a function pointer.

In C, the callbacks registered with an API are usually specified to take a void * which holds "user context." This is where you would store the pointer to the object instance. If the API does not provide such a parameter to the callback, then you are out of luck. The API is badly made.

EDIT: This is an example of how it would work, if the API did provide you with a context parameter:

Code:

int my_callback(void *user_param)
{
    Foo *f = reinterpret_cast<Foo *>(user_param);
    return f->some_func();
}

EDIT EDIT: Whoops, I was using static_cast<> before, which wasn't right.

Originally Posted by pheres

Why are that smart people that are able to design such complex languages and compilers and OS'es not willing to store and process such 3 simple 3-tuple?

Ok, so you are asking why every single call-back capable call isn't taking three pointers instead of one? Because when the Windows NT design was made, it was 1995 or so. At that time, computers had 64MB of RAM if they were "big memory" and "fully fitted with RAM in all sockets". Saving memory in such a situation by not wasting two longwords worth of space, that most people aren't using anyways, because much of the code at that time was still C, not C++. [And it shouldn't be too different from the Windows 3.1 API that was designed even longer ago, when machines had even less memory].

Unfortunately, comletely scrapping the current API and replacing it with a new one isn't very likely to happen anytime real soon - because it either means that there would have to be two ways to do just about everything except new functions, or you'd need a "translation layer" - and this would be fine for most things, but some speed critical stuff would then not be quite as fast in the new OS as in the old one. Which means that anyone running either the slower version will complain that "this new API makes my application slower - please take it back".

--
Mats