The dreaded question

[caustik]

I don't care if its bad C++, I really dont. I need to convert from
a member function pointer to a "void*" with zero computational
overhead.

I have the perfect way to do it right here, but i'm having troubles
because if the member function pointer i pass to the function is
not void with no params, I get a casting error.

Any ideas how to do this?

caustik

// ******************************************************************
// * Take THIS C++ !!
// ******************************************************************
template <class BaseClass> inline void *MFPtoFP( void
(BaseClass::*pMemFunc)(void) )
{
union
{
void BaseClass::*pMemFunc;
void *pFunc();
}
ThisConv;

ThisConv.pFunc = pMemFunc;

return ThisConv.pFunc;
}

 

[Victor Bazarov]

I don't care if its bad C++, I really dont. I need to convert from
a member function pointer to a "void*" with zero computational
overhead.

A pointer to member cannot be converted to void*. Period. It's
not "bad C++", it's "not C++". Such conversion does not exist
in C++.

I have the perfect way to do it right here, but i'm having troubles

So, if you're "having troubles", how can it be "perfect"?

because if the member function pointer i pass to the function is
not void with no params, I get a casting error.

Any ideas how to do this?

There is no way.

Now, let me ask you a question. Why do you think you need that?

caustik

// ******************************************************************
// * Take THIS C++ !!
// ******************************************************************
template <class BaseClass> inline void *MFPtoFP( void
(BaseClass::*pMemFunc)(void) )
{
union
{
void BaseClass::*pMemFunc;
void *pFunc();

You could declare this as

void (*pFunc)();

but it's _not_ going to solve the conversion problem, trust me.
It will probably get rid of the "casting error", as you put it,
but it's not going to give the right answer.

}
ThisConv;

ThisConv.pFunc = pMemFunc;

return ThisConv.pFunc;
}

Victor

 

[Cy Edmunds]

I don't care if its bad C++, I really dont.

Well, then, I don't care if it works. I really don't.

lol

See Victor's answer.

Cy

 

[caustik]

A pointer to member cannot be converted to void*. Period. It's
not "bad C++", it's "not C++". Such conversion does not exist
in C++.

Damn, you know that I stated I dont care. There are tricks to do it,
and I dont give a flying crap if they arent technically legal.

So, if you're "having troubles", how can it be "perfect"?

Well, fool, the method is "perfect" because it works 100% of the time
in my program. I happen to know the system that my program is compiled
and executed on, so I can take advantages of facts about that system.

I suppose I am ignorant to dare to optimize my program.

There is no way.

Bullshit, I did it already.

Now, let me ask you a question. Why do you think you need that?

Let me rephrase your question: Why do you [smart ass remark] need that?

The reason is that I have a massive array of generic pointers to functions,
and their respective "Wrapper" functions which are called when the binary
code for these intercepted functions is executed. The problem is that some
of these functions are "__thiscall", and the intercepted code must take this
into account.

Believe it or not, not everbody's C++ program can be efficient while obeying
every single anal object oriented design rule on the planet. I am
interfacing
with already-compiled C++ code, so it takes some "Hacks" to get it working
efficiently and without looking like utter garbage.

After several years of reading this newsgroup, I've noticed there is some
sort
of deep rooted psychological problem with some of you guys. You'd sooner
spend 30 minutes typing a lengthy "I'm above everybody" post to respond to
peoples slightly offtopic or anal-incomplatible questions, instead of
posting a
quick solution and saying "note that this is a hack". Its horrible.

 

[caustik]

P.S. This works *Pefectly* (on my x86/win32 system, which is all i'm
targetting) :

// ******************************************************************
// * Take THIS C++ !!
// ******************************************************************
template <class BaseClass, typename MFT> inline void *MFPtoFP( MFT pMemFunc)
{
union
{
MFT pMemFunc;
void (*pFunc)();
}
ThisConv;

ThisConv.pMemFunc = pMemFunc;

return ThisConv.pFunc;
}

 

[Andre Kostur]

P.S. This works *Pefectly* (on my x86/win32 system, which is all i'm
targetting) :

Since you know your target platform, why don't you take your question over
to a newsgroup that caters to your target platform (and since you
apparently already know that it cannot be done in Standard C++)? I'd
suggest one of the newsgroups on Microsoft's news server probably being the
most topical.

 

[E. Robert Tisdale]

I don't care if its bad C++, I really don't. I need to convert from
a member function pointer to a "void*" with zero computational
overhead.

I have the perfect way to do it right here, but I'm having troubles
because if the member function pointer i pass to the function is
not void with no params, I get a casting error.

Any ideas how to do this?

caustik

// ******************************************************************
// * Take THIS C++ !!
// ******************************************************************
template <class BaseClass> inline void *MFPtoFP( void
(BaseClass::*pMemFunc)(void) )
{
union
{
void BaseClass::*pMemFunc;
void *pFunc();
}
ThisConv;

ThisConv.pFunc = pMemFunc;

return ThisConv.pFunc;
}

This is an obvious troll. Please ignore it.

 

[Default User]

Damn, you know that I stated I dont care. There are tricks to do it,
and I dont give a flying crap if they arent technically legal.

Yeah . . . I going to need you to go into my killfile. Yeah . . . move
all the way to the back. Thanks, that'll be great.




Brian Rodenborn

 

[Michael Furman]

[...]
If you really want to do this, C++ offers a far easier route. You can
convert anything to anything, with zero computational cost:

#include <vector>
#include <list>
#include <string>

template <class T, class U>
inline
T just_do_it(const U& u)
{
return *(T*)(&u);
}

int main()
{
std::vector<int> v =
just_do_it<std::vector<int> >(std::list<std::string>());
}

... not that I'm recommending it mind you. Here's the rope ...

I would recomment much more safe and effective solution to "convert"
anything
to void pointer:

#define convert_to_pointer(argument) ((void *)0)

regards,
Michael Furman

 

[David White]

This is an obvious troll. Please ignore it.

I don't know if it's a troll or not, but it clearly wasn't obvious to all
those who answered the question.

Is it just the email address that makes it a troll?

Just wondering.

David

 

[Jack Klein]

Damn, you know that I stated I dont care. There are tricks to do it,
and I dont give a flying crap if they arent technically legal.


Well, fool, the method is "perfect" because it works 100% of the time
in my program. I happen to know the system that my program is compiled
and executed on, so I can take advantages of facts about that system.

If you know, and don't care, that's is not legal C++, and yet you post
it in comp.lang.c++ and display an insulting attitude to those who
tell you is it not legal C++, you are the one with the psychological
problem.

*PLONK*

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[E. Robert Tisdale]

I don't know if it's a troll or not,
but it clearly wasn't obvious to all those who answered the question.

Is it just the email address that makes it a troll?

Just wondering.

I was simply expressing my opinion.
I look for the typical signs:

1. a troll handle
caustik,
2. a forged or disposable email account
nospam.com,
3. an emotionally provocative subject
The dreaded question
4. the original poster does not participate in the discussion
(except, possibly, to abuse the respondents)

There is seldom a good reason why a legitimate post
to a technical newsgroup like comp.lang.c++
should evoke a strong emotional response in any subscriber.
If it does, you should suspect a troll.
Real people use real names and post from legitimate ISPs.
Trolls use handles and post from disposable email accounts
or just forge the the address so you can't trace them.
Be vigilant. Learn to recognize trolls
and don't respond to them.

 

[tom_usenet]

I don't care if its bad C++, I really dont. I need to convert from
a member function pointer to a "void*" with zero computational
overhead.

sizeof memfunptr on VC++ can be 4, 8 or 12 (and possibly bigger?),
depending on the function and class in question. Size of void(*)() is
4. As you can see, a non-lossy conversion is impossible in general.

I have the perfect way to do it right here, but i'm having troubles
because if the member function pointer i pass to the function is
not void with no params, I get a casting error.

It isn't perfect even if you fix it - if the classes involved have
virtual base classes, or you use multiple inheritence, then you'll get
a crash. If they don't, you may be ok with your current version, but
it may of course start crashing next time you upgrade, or if you
switch to another compiler.

Tom

 

[Alexander Terekhov]

I don't care if its bad C++, I really dont.

Yeah. But it *might* not work even on "x86/win32 system", believe me.

I need to convert from
a member function pointer to a "void*" with zero computational
overhead.

Stay away from "void*".

I have the perfect way to do it right here, but i'm having troubles
because if the member function pointer i pass to the function is
not void with no params, I get a casting error.

Any ideas how to do this?

Sure. http://groups.google.com/[email protected]

regards,
alexander.

 

[Alexander Terekhov]

Default User wrote:
[...]

Yeah . . . I going to need you to go into my killfile. Yeah . . . move
all the way to the back. Thanks, that'll be great.

I'm just curious: how BIG is your killfile? Well, I'm asking because
I'd be interested to buy a copy of it... if it's "big enough", so to
speak. ATTENTION: this "offer" is valid for all c.l.c++'s "plonkers"
from The United States (only) and will last until the end of The 226th
Independence Day (in all US time zones... uhmm, except Alaska, Hawaii,
and Samoa, sorry for that). Hurry up and act NOW! I need _only_one_
copy -- the BIGGEST one.

regards,
alexander.

P.S. Default, did you appreciate "the e-greetings" from Berlin City
Dump... did it arrive yet?

 

[Phlip]

I don't care if its bad C++, I really dont. I need to convert from
a member function pointer to a "void*" with zero computational
overhead.

Why?

Answering why might lead us to a suggestion that's good for your code.

(BTW the answer is: put the member function pointer into a structure, take
the address of the structure, and cast away. Good luck not crashing.)

 

[Ron Natalie]

P.S. This works *Pefectly* (on my x86/win32 system, which is all i'm
targetting) :

How can it work perfectly? On VC++ the sizeof(MPT) is some where
between 2 and 4 times the sizeof (void*)?

 

[Steve Coleman]

I was simply expressing my opinion.
I look for the typical signs:

1. a troll handle
caustik,
2. a forged or disposable email account
nospam.com,

Well, they can try to anyway... ;-)

NNTP-Posting-Host: sandiego.divxnetworks.com
X-Trace: eeyore.INS.cwru.edu 1057183867 12825
207.67.92.110 (2 Jul 2003 22:11:07 GMT)
X-Complaints-To: (e-mail address removed)
NNTP-Posting-Date: 2 Jul 2003 22:11:07 GMT
NNTP-Posting-User: (e-mail address removed)

In answer to the actual question...

If performance is so much of an issue that it becomes socially
acceptable to insult those that might try to help (even before asking
the question), then what's wrong with just coding an ASM var push/pop or
register move and be done with it? *That* will convert most anything! ..
and also ignore all language usage restrictions (aka. protections) in
the process. IMHO one beauty in the C++ language is that it _has_ these
restrictions, and all for good reason! To prevent someone from abusing
the usage of known types in a manner which is undefined or incorrect.

On the other hand my glass is always half full, and given the latest
description of the problem from the original poster perhaps we should
discuss the correct manner to address his issues rather than getting so
wrapped up in the emotionally charged aspects of it. Do we have enough
to go on for a C++ design discussion here? Can anyone out there suggest
a *better solution*[tm] USING the C++ language instead of trying to
fight against it(e.g. unions of pointers)? I'm sure that others out
there who are learning C++ might benefit from a discussion of C++ design
rather than a food fight (lol).

 

[Default User]

Default User wrote:
[...]

Yeah . . . I going to need you to go into my killfile. Yeah . . . move
all the way to the back. Thanks, that'll be great.

I'm just curious: how BIG is your killfile?

Don't worry Al, there's a place for you if you really need it.



Brian Rodenborn

 

[Default User]

There is seldom a good reason why a legitimate post
to a technical newsgroup like comp.lang.c++
should evoke a strong emotional response in any subscriber.
If it does, you should suspect a troll.

Well, I feel that way about many of your posts, especially on
comp.lang.c.




Brian Rodenborn