Casting function pointers to and from void*

**Noah Roberts** · Jan 5 '07, 05:05 PM

Re: Casting function pointers to and from void*

Peter Olcott wrote:

I want to make a generic interface between a scripting language and native code,
the native code and the interpreter will both be written in C++. The interpreter
will probably be implemented as a subset of C/C++, thus will have the same
syntax as C/C++.
>
Somehow the interpreted code must be able to store generic function pointers
because there is no way for the interpreter to know every possible function
signature in advance. I was thinking about casting them to void* for this
purpose.
>
The interpreted function will be provided with the generic function pointer, and
the function prototype as text. The interpreter will prepare the stack itself
based on this function prototype. What I want to end up with is a simple
interface for users of the interpreter that is identical to the interface for
the native code users.
>
In other words if the function prototype is:
int FunctionName(in t N);
I want uses of my interpreter to be able to specify:
int Result = FunctionName(56 );
when they are calling the native code functions.
>
What kind of C++ syntax will be needed for this?

I don't understand your problem as stated but maybe boost::function
will aid you.

**Philipp Reh** · Jan 5 '07, 05:55 PM

Re: Casting function pointers to and from void*

On Fri, 05 Jan 2007 10:21:46 -0600, Peter Olcott wrote:

I want to make a generic interface between a scripting language and native code,
the native code and the interpreter will both be written in C++. The interpreter
will probably be implemented as a subset of C/C++, thus will have the same
syntax as C/C++.
>
Somehow the interpreted code must be able to store generic function pointers
because there is no way for the interpreter to know every possible function
signature in advance. I was thinking about casting them to void* for this
purpose.
>
The interpreted function will be provided with the generic function pointer, and
the function prototype as text. The interpreter will prepare the stack itself
based on this function prototype. What I want to end up with is a simple
interface for users of the interpreter that is identical to the interface for
the native code users.
>
In other words if the function prototype is:
int FunctionName(in t N);
I want uses of my interpreter to be able to specify:
int Result = FunctionName(56 );
when they are calling the native code functions.
>
What kind of C++ syntax will be needed for this?

You can't cast a pointer to a function to a pointer to an object.
reinterpret_cas t can convert between two pointers to different functions
only.

**Peter Olcott** · Jan 5 '07, 06:35 PM

Re: Casting function pointers to and from void*

"Philipp Reh" <sefi@s-e-f-i.dewrote in message
news:459e9093$1 @news.uni-siegen.de...

On Fri, 05 Jan 2007 10:21:46 -0600, Peter Olcott wrote:
>

>I want to make a generic interface between a scripting language and native
>code,
>the native code and the interpreter will both be written in C++. The
>interpreter
>will probably be implemented as a subset of C/C++, thus will have the same
>syntax as C/C++.
>>
>Somehow the interpreted code must be able to store generic function pointers
>because there is no way for the interpreter to know every possible function
>signature in advance. I was thinking about casting them to void* for this
>purpose.
>>
>The interpreted function will be provided with the generic function pointer,
>and
>the function prototype as text. The interpreter will prepare the stack itself
>based on this function prototype. What I want to end up with is a simple
>interface for users of the interpreter that is identical to the interface for
>the native code users.
>>
>In other words if the function prototype is:
> int FunctionName(in t N);
>I want uses of my interpreter to be able to specify:
> int Result = FunctionName(56 );
>when they are calling the native code functions.
>>
>What kind of C++ syntax will be needed for this?

>
You can't cast a pointer to a function to a pointer to an object.
reinterpret_cas t can convert between two pointers to different functions
only.

Is there any standard C++ way to accomplish what I need to accomplish?

**Peter Olcott** · Jan 5 '07, 06:55 PM

Re: Casting function pointers to and from void*

"Philipp Reh" <sefi@s-e-f-i.dewrote in message
news:459e9093$1 @news.uni-siegen.de...

On Fri, 05 Jan 2007 10:21:46 -0600, Peter Olcott wrote:
>

>I want to make a generic interface between a scripting language and native
>code,
>the native code and the interpreter will both be written in C++. The
>interpreter
>will probably be implemented as a subset of C/C++, thus will have the same
>syntax as C/C++.
>>
>Somehow the interpreted code must be able to store generic function pointers
>because there is no way for the interpreter to know every possible function
>signature in advance. I was thinking about casting them to void* for this
>purpose.
>>
>The interpreted function will be provided with the generic function pointer,
>and
>the function prototype as text. The interpreter will prepare the stack itself
>based on this function prototype. What I want to end up with is a simple
>interface for users of the interpreter that is identical to the interface for
>the native code users.
>>
>In other words if the function prototype is:
> int FunctionName(in t N);
>I want uses of my interpreter to be able to specify:
> int Result = FunctionName(56 );
>when they are calling the native code functions.
>>
>What kind of C++ syntax will be needed for this?

>
You can't cast a pointer to a function to a pointer to an object.
reinterpret_cas t can convert between two pointers to different functions
only.

void Test() {
printf("Hello World!\n");
}

void (*pf)() = Test;

void* vp = (void*) pf;

This all compiles and executes correctly on my compiler.

// All I need now is something like:
goto *vp;
// sets the instruction pointer to the address contain in vp.

Is there anyway that anything like this can be done in standard C++ ???

**Marcus Kwok** · Jan 11 '07, 07:15 PM

Re: Casting function pointers to and from void*

Peter Olcott <NoSpam@seescre en.comwrote:

void Test() {
printf("Hello World!\n");
}
>
void (*pf)() = Test;
>
void* vp = (void*) pf;
>
This all compiles and executes correctly on my compiler.

Even though it *seems* to work, it is not correct.

Pointers to member functions, C++ FAQ

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

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

**Peter Olcott** · Jan 11 '07, 08:35 PM

Re: Casting function pointers to and from void*

"Marcus Kwok" <ricecake@gehen nom.invalidwrot e in message
news:eo61fo$4k4 $1@news-int2.gatech.edu ...

Peter Olcott <NoSpam@seescre en.comwrote:

>void Test() {
> printf("Hello World!\n");
>}
>>
>void (*pf)() = Test;
>>
>void* vp = (void*) pf;
>>
>This all compiles and executes correctly on my compiler.

>
Even though it *seems* to work, it is not correct.

It indeed does work, I checked the generated assembly language. It only has to
work on a single platform/compiler. When getting the job done requires breaking
the rules, the rules must be broken.

>

Pointers to member functions, C++ FAQ

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

>
--
Marcus Kwok
Replace 'invalid' with 'net' to reply

**=?ISO-8859-15?Q?Juli=E1n?= Albo** · Jan 11 '07, 08:45 PM

Re: Casting function pointers to and from void*

Peter Olcott wrote:

When getting the job done requires breaking the rules, the rules must be
broken.

Please don't blame the job when it's you who decide to break the rules.

--
Salu2

**Marcus Kwok** · Jan 11 '07, 08:55 PM

Re: Casting function pointers to and from void*

Peter Olcott <NoSpam@seescre en.comwrote:

>
"Marcus Kwok" <ricecake@gehen nom.invalidwrot e in message
news:eo61fo$4k4 $1@news-int2.gatech.edu ...

>Peter Olcott <NoSpam@seescre en.comwrote:

>>void Test() {
>> printf("Hello World!\n");
>>}
>>>
>>void (*pf)() = Test;
>>>
>>void* vp = (void*) pf;
>>>
>>This all compiles and executes correctly on my compiler.

>>
>Even though it *seems* to work, it is not correct.

>
It indeed does work, I checked the generated assembly language. It only has to
work on a single platform/compiler. When getting the job done requires breaking
the rules, the rules must be broken.

Sure, but then it is no longer Standard C++. Sorry, I don't have an
answer to your real question. Maybe someone on a group for your
platform or compiler will have a suggestion that is known to work for
your situation.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

**Peter Olcott** · Jan 11 '07, 09:15 PM

Re: Casting function pointers to and from void*

"Julián Albo" <JULIANALBO@ter ra.eswrote in message
news:45a6a0d6_2 @x-privat.org...

Peter Olcott wrote:
>

>When getting the job done requires breaking the rules, the rules must be
>broken.

>
Please don't blame the job when it's you who decide to break the rules.
>
--
Salu2

I don't have to get my system working in theory, I have to get it working in
practice. If it does not work in theory yet does work in practice, then the
theory is discarded.

**Peter Olcott** · Jan 11 '07, 09:15 PM

Re: Casting function pointers to and from void*

"Marcus Kwok" <ricecake@gehen nom.invalidwrot e in message
news:eo67j5$66s $1@news-int2.gatech.edu ...

Peter Olcott <NoSpam@seescre en.comwrote:

>>
>"Marcus Kwok" <ricecake@gehen nom.invalidwrot e in message
>news:eo61fo$4k 4$1@news-int2.gatech.edu ...

>>Peter Olcott <NoSpam@seescre en.comwrote:
>>>void Test() {
>>> printf("Hello World!\n");
>>>}
>>>>
>>>void (*pf)() = Test;
>>>>
>>>void* vp = (void*) pf;
>>>>
>>>This all compiles and executes correctly on my compiler.
>>>
>>Even though it *seems* to work, it is not correct.

>>
>It indeed does work, I checked the generated assembly language. It only has
>to
>work on a single platform/compiler. When getting the job done requires
>breaking
>the rules, the rules must be broken.

>
Sure, but then it is no longer Standard C++. Sorry, I don't have an
answer to your real question. Maybe someone on a group for your
platform or compiler will have a suggestion that is known to work for
your situation.

I was able to infer that casting to a specific function pointer type would not
generally be possible. It would not generally be possible because the function
pointer requires the compile time support of preparing the stack.

>
--
Marcus Kwok
Replace 'invalid' with 'net' to reply

**Gavin Deane** · Jan 12 '07, 12:45 PM

Re: Casting function pointers to and from void*

Peter Olcott wrote:

I don't have to get my system working in theory, I have to get it working in
practice. If it does not work in theory yet does work in practice, then the
theory is discarded.

The problem you create for yourself when you take this approach is that
you have no way of knowing for how long your solution will continue to
work in practice. Examining the generated assembly language is a valid
way of checking that the behaviour in practice of your code is what you
want when the behaviour in theory is formally undefined. However,
unless your compiler documents the behaviour in practice as an
extension (which it may well do), you have no way of knowing how stable
the behaviour in practice is in the face of changes, such as compiler
options, debug vs release build, or a change in the code itself. Your
code is potentially very brittle. Every time you change something and
recompile, you have to reexamine the generated assembly language to see
if you still have the behaviour in practice that you need.

Only you know how likely such changes and the associated need to
recompile are, so only you are in a position to assess the relative
costs of losing robustness in the code vs. redesigning to avoid the
problem in the first place. But it is an assessment you must make.

Gavin Deane

**Greg** · Jan 12 '07, 12:55 PM

Re: Casting function pointers to and from void*

Marcus Kwok wrote:

Peter Olcott <NoSpam@seescre en.comwrote:

"Marcus Kwok" <ricecake@gehen nom.invalidwrot e in message
news:eo61fo$4k4 $1@news-int2.gatech.edu ...

Peter Olcott <NoSpam@seescre en.comwrote:
>void Test() {
> printf("Hello World!\n");
>}
>>
>void (*pf)() = Test;
>>
>void* vp = (void*) pf;
>>
>This all compiles and executes correctly on my compiler.
>
Even though it *seems* to work, it is not correct.

It indeed does work, I checked the generated assembly language. It only has to
work on a single platform/compiler. When getting the job done requires breaking
the rules, the rules must be broken.

>
Sure, but then it is no longer Standard C++. Sorry, I don't have an
answer to your real question. Maybe someone on a group for your
platform or compiler will have a suggestion that is known to work for
your situation.

Function-to-object pointer conversions have been added to standard C++
as a "conditiona lly supported" conversion using reinterpret_cas t<>:

"Converting a pointer to a function into a pointer to an object type or
vice versa is conditionally-supported. The meaning of such a conversion
is implementation defined, except that if an implementation supports
conversions in both directions, converting an rvalue of one type to the
other type and back, possibly with different cv-qualification, shall
yield the original pointer value." [expr.reinterpre t.cast/8]

Conditionally-supported behavior is one that an implementation is not
required to support. But an implementation does support the feature
must then implement the feature as specified.

Greg

**Pete Becker** · Jan 12 '07, 01:35 PM

Re: Casting function pointers to and from void*

Gavin Deane wrote:

Peter Olcott wrote:

>I don't have to get my system working in theory, I have to get it working in
>practice. If it does not work in theory yet does work in practice, then the
>theory is discarded.

>
The problem you create for yourself when you take this approach is that
you have no way of knowing for how long your solution will continue to
work in practice. Examining the generated assembly language is a valid
way of checking that the behaviour in practice of your code is what you
want when the behaviour in theory is formally undefined. However,
unless your compiler documents the behaviour in practice as an
extension (which it may well do), you have no way of knowing how stable
the behaviour in practice is in the face of changes, such as compiler
options, debug vs release build, or a change in the code itself. Your
code is potentially very brittle. Every time you change something and
recompile, you have to reexamine the generated assembly language to see
if you still have the behaviour in practice that you need.
>
Only you know how likely such changes and the associated need to
recompile are, so only you are in a position to assess the relative
costs of losing robustness in the code vs. redesigning to avoid the
problem in the first place. But it is an assessment you must make.
>

Despite all these dire threats, Unix programmers have been storing
function pointers in void*'s for years. I'd even be so bold as to
suggest that any compiler that didn't suppport this idiom on a Unix
system where code and data pointers are the same size would be a
failure. At the end of the day, it's more important to have code that
works than to be hypothetically pure.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

**=?ISO-8859-15?Q?Juli=E1n?= Albo** · Jan 12 '07, 03:25 PM

Re: Casting function pointers to and from void*

Pete Becker wrote:

Despite all these dire threats, Unix programmers have been storing
function pointers in void*'s for years.

An many unix or non unix programs have failed to work when compiled on
different machines or compilers for decades. Maybe there are some
correlation...

--
Salu2

Casting function pointers to and from void*

Casting function pointers to and from void*

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment