Get a Pointer to a Memberfunction

Re: /*So this is you final answer? Then could you provide me wit...

24-Feb-11 4:58

Reason for my vote of 1
Introduces a concept which intentionally evades compiler checks, thereby resulting in non-standard, and unsafe code.

Ansas Bogdan24-Feb-11 6:13

24-Feb-11 6:13

/*So this is you final answer? Then could you provide me with a sample where this actually fails to proof that you are correct? Or are you just unable to lose a debate ?.*/

Ok i admid my previous version didnt work in certain cases. But this actually even works in that cases and scince the compiler does the same i dont think this way would ever fail.

FAIL !!!!

damnedyankee23-Feb-11 23:16

23-Feb-11 23:16

Please read:

http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.10
and
http://www.parashift.com/c++-faq-lite/pointers-to-members.html#faq-33.11

Please do more research befefore posting more articles about subjects you don't understand

Ansas Bogdan24-Feb-11 2:35

24-Feb-11 2:35

My way actually works despite what your faq might say.
This will give you the virtual adress of the member function making it possible to actually call it via ptrtomemberfunc(thisptr,args...); [if you convert it to a matching function ptr ofc].
Testing things before marking them as fail might be a good idea Wink | ;)

damnedyankee24-Feb-11 2:36

24-Feb-11 2:36

You clearly haven't learned anything from the referenced web site.

Ansas Bogdan24-Feb-11 2:40

24-Feb-11 2:40

[quote]Can I convert a pointer-to-member-function to a void*?[/quote]
[quote]No! [/quote]

thats what you website states. But my solution actually casts it to a void*. It also works for virtual member funcs so ...

damnedyankee24-Feb-11 3:19

24-Feb-11 3:19

Which part of this:

<br />
FredMemFn p = &Fred::f;<br />
void* p2 = (void*)p;                  // ← illegal!!<br />

do you find confusing ?

Ansas Bogdan24-Feb-11 3:58

24-Feb-11 3:58

Well i know... thats why i posted this code. As Programmer you should think of how to overcome restiritcions instead of dont do something because its not part of C++. If it would be part of C++ standard there wouldnt be any need for my function cause you could just typecast.

Not doing something that works because its not standard of C++ is just stupid in my opinion.

damnedyankee24-Feb-11 4:09

24-Feb-11 4:09

I think you are missing the point. The compiler emits an error because it's wrong to do. You are merely circumventing the compiler error, hell, you even state so: "...So I fooled the compiler...". Don't believe me, search about on the internet for other explanations of why it's wrong.

Just please don't use this in aircraft autopilot code !

Ansas Bogdan24-Feb-11 4:45

24-Feb-11 4:45

I think you are missing the point. This isnt for aircraft autopilot code or anything amongst the lines. Its barely a way to circumvent compiler restrictions. It might not always be stable and there may be compilers where this trick doesnt work. The point is in VC 8.0 this actually works scince Memberfunction pointers are only "normal" pointers. Only the compiler would prevent you from casting it to a void*. So why dont use something when it works. I mean ofcourse for Programs where you need to be 100% sure that it will never fail and that it compiles with every compiler out there you shouldnt use this but as far as i can say this works with VC 8.0 if you have any example where this doesnt work then let me know. In fact there is barely any Situation where you actually need this. I needed this and i thought i would share my findings with others and that is what this Section is for:
[quote]Tips n tricks are meant to be very, very short tips, snippets or even just a one-liner you came across that saved your day[/quote]
If you dont like my solution just dont use it but declaring something as fail that actually works just because it cause its not supported and thus may not work on every compiler is just ...
And yes i am fully aware that you shouldnt do this but this doesnt stop me from doing so when i need it as long as it works! In fact doing things that shouldnt be done is how many things in history where developed. So dont deny something cause of the simple fact that you shouldnt do it.

And if you take a look at the Tags i set for this article youll see that they state C++, VC 8.0.

nv325-Feb-11 0:04

nv3

25-Feb-11 0:04

Ansas, try to do your "trick" with a member function of a class that has a virtual base class and you will see why it fails. Your assumption that pointers to member functions have the same length as a simple void* is not correct. Therefore, your "trick" might lead to nasty crashes that are extremely hard to debug.

You should read for example this article, in order to understand what's going on:
Member Function Pointers and the Fastest Possible C++ Delegates

Quote from that article: "On almost all compilers, a member function pointer is bigger than a function pointer. Most bizarrely, in Visual C++, a member function pointer might be 4, 8, 12, or 16 bytes long, depending on the nature of the class it's associated with, and depending on what compiler settings are used!"

Therefore, I find the trick you are proposing a very dangerous technique. You should have researched to subject a little deeper.

Re: FAIL !!!! [modified]

Ansas Bogdan25-Feb-11 1:51

"So why dont use something when it works"

25-Feb-11 1:51

http://pastebin.com/tEX18XMv[^]
works perfectly fine for me so ... if you want i can give you the full source but this definately works. atleast in vc 8.0

F(...) is an instance of a foreign function interface i wrote.

€: oh and it even works with multiple inheritance.
€2: by looking at the disassembly it looks like the compiler predicts that you want to do something like __asm call eax and thus gives you a valid ptr.
€3: Ok i must admit there are situations where this fails. BUT i found another way that abuses how the compiler implements these calls. Though this might be very compiler specific too it should never fail. Well the downside is you cant pack this in a function.

<br />
void* p;<br />
__asm MOV eax,offset MyClass::MyFunction<br />
__asm MOV p,eax<br />
/*__asm CALL eax*/<br />

Tested on VC 8.0 and works with __single_inheritance, __multiple_inerhitance and normal classes.

Ill edit the tip.

modified on Friday, February 25, 2011 9:39 AM

imagiro25-Feb-11 4:48

imagiro

25-Feb-11 4:48

I'm sorry, but no. I'm currently working for a guy who did his whole website like this, and he ignored nearly all basic guidelines. Just had it today: Why doing a htmlentities when writing values to a html-form, it works also without. So, now one of the customers installed the software and entered a password like ald"dl3 for his database. Result: Form doesn't work, and, in combination with other "why not, it works"-things deletes all settings when saved.

So the last months I spent finding and removing errors of things that "worked" so far.

There is a reason why things are marked as errors by compilers and experts.

Re: "So why dont use something when it works"

Ansas Bogdan25-Feb-11 5:02

25-Feb-11 5:02

well the compiler must be able to do this as well scince asm actually can only call 32bit addresses (on x86) so there must be a way for the compiler to get this address and if the compiler is able to you should be able to do so too dont you agree ?

libsigc++

Tomaž Štih23-Feb-11 20:23

Tomaž Štih

23-Feb-11 20:23

I like your solution. It is probably not as portable as it could be but it is very compact and a way to go in environments with constraints. An alternative to this (if you don't mind extra bytes and libraries) is using industry standard libsigc++.

Re: libsigc++

Ansas Bogdan24-Feb-11 2:49