Function pointers

[Jan-Henrik Grobe]

Hallo,

I am coming to this newsgroup with a very strange Problem. I have two c++
files A.cpp and B.cpp....In A.cpp I am creating an openGL window and in
B.cpp I have stored the callback functions. Important is, that the object
A.o has to be created BEFORE B can be compiled. I am sure that sounds
confusing but A.cpp is part of a library that is needed for objects I use in
B (kind of client-server thing). So I cannot include a B.h in the A.cpp. But
B.cpp has an include A.h. I thought of using function pointers and my code
looks something like this:

In A.h the function pointer is defined

A.h

....
extern void (*pDisplay)(voi d); // Definition of a function
pointer pDisplay
....

Because I have to use "extern" (doesnt work other) I have to declare
something to the pointer in A.cpp. I thought of using a dummy funtion:

A.cpp

void dummy(void)
{
cout << I am a stupid dummy function <<;
}

pDisplay = dummy; // assign adress to dummy to pDisplay (NULL doesnt
work)


later I create an open GL window and give the pointer as the display
callback

....
window = glutCreateWindo w(...);
glutDisplayFunc (pDisplay);


But the function that should be the display function is in B.cpp


B.cpp

....
void displayWindow(v oid)
{
// Displaycallback function
}


B is exectueable and has a main function. There...first an object has to be
created that uses a library that contains A.cpp ... then I want to pass
displayWindow to the pointer pDisplay that is defined in A.h

int main (argc, argv)
{

create an object O;

pWindow = displayWindow; // assign displayWindow to the pointer
pDisplay


ok....the code compiled and linked fine. The problem now is, when I execute
it, that the pointer pDisplay keeps the whole time the adress of the dummy
function and not the adress of displayWindow. I thought you can assign
functions to pointers at the runtime somehow. If I assign the adress of
displayWindow to the pointer before the object O is created, I get a memory
error. In my opinion it must have something to do with the keyword "extern"
in the A.h. If I wouldnt need to declare the pointer in the A.cpp then maybe
I wont have this problem. Unhappily I am not very familiar with function
pointers. I used information i found in the net but obviously with less
success. Maybe one of you has a little hint for me or a good advise.

Many thanks
Jan-Henrik

[rajkumar@hotmail.com]

Re: Function pointers

Unfortunately what you have written is pretty vague... and i can only
guess what the problem might be....maybe every translation unit is
getting its own pDisplay

Try this... always use typedefs ... it is much cleaner and easier to
understand. Also you will make less typoes

typedef void (*MYDISPLAYFUNC PTR)(void);


If A builds first.... in some cpp file in A instead of global variable
do this

MYDISPLAYFUNCPT R current_display func = 0;

MYDISPLAYFUNCPT R getDisplayFunct ion()
{
return current_display func;
}


void setDisplayFunct ion( MYDISPLAYFUNCPT R funcIn)
{
current_display func = funcIn;
}


Now instead of updating a global variable you are calling functions and
you can step in the debugger to see if it sets/gets right.

Raj

[Jan-Henrik Grobe]

Re: Function pointers

Hallo Ray, others,

thank you for your help...Sadly my problem isnt really away. My code looks
now somewhat like this

A.h

....
typedef void(*MYDISPLAY FUNCPTR)(void); // pointer typedef

extern MYDISPLAYFUNCPT R current_display func; // declare new FUNCPTR



MYDISPLAYFUNCPT R getDisplayFunct ion(void); // get/set
prototypes

void setDisplayFunc( MYDISPLAYFUNCPT R funcIn);



A.cpp

MYDISPLAYFUNCPT R current_display func = 0; // init current_display
with a dummy





MYDISPLAYFUNCPT R getDisplayFunct ion(void) // get/set
functions

{

return current_display func;

}



void setDisplayFunc( MYDISPLAYFUNCPT R funcIn)

{

current_display func = funcIn;

}

....

//window creation

glutInitWindowP osition(500, 500);

int gmlWin = glutCreateWindo w ("GML-Window");

glutDisplayFunc (getDisplayFunc tion());

....



B.cpp (main)



glutInit(&argc, argv);

cav = new Cav((2*sizeof(f loat)+sizeof(in t));

data = (DemoData*)dave->getSyncBuffer( );

memset(data, 0, 2*sizeof(float) +sizeof(int));

gml = new GML();

setDisplayFunc( wallDisplay); // let current_display pint on
wallDisplay



Important to know here is, that for a Cav-Objekt the file A.cpp has to be
compiled because it is used there. Further its not possible to call
setDisplayFunc before cav is build because it contains function calls from
the GML-object gml. The only way it to call setDisplayFunct ion is behind the
creation of the Cav-Object and the GML-object.

It seems, if I run this code now, that the setDisplayFunc function isnt
executed properly, because current_display func keeps the value 0 (which
leads to a NULL display callback error). If I exchange the 0 against the
dummy func, its always executed. But I wish to use the wallDisplay-Function
that stands in B.cpp.

The strange thing is, that I can use a similar code under windows (VC++.NET
2003) that works well. Somehow it has to work under Linux, too.

Does anyone has any suggestions?

Greetings

Jan-Henrik






<rajkumar@hotma il.com> schrieb im Newsbeitrag
news:1111173931 .113829.160140@ z14g2000cwz.goo glegroups.com.. .[color=blue]
> Unfortunately what you have written is pretty vague... and i can only
> guess what the problem might be....maybe every translation unit is
> getting its own pDisplay
>
> Try this... always use typedefs ... it is much cleaner and easier to
> understand. Also you will make less typoes
>
> typedef void (*MYDISPLAYFUNC PTR)(void);
>
>
> If A builds first.... in some cpp file in A instead of global variable
> do this
>
> MYDISPLAYFUNCPT R current_display func = 0;
>
> MYDISPLAYFUNCPT R getDisplayFunct ion()
> {
> return current_display func;
> }
>
>
> void setDisplayFunct ion( MYDISPLAYFUNCPT R funcIn)
> {
> current_display func = funcIn;
> }
>
>
> Now instead of updating a global variable you are calling functions and
> you can step in the debugger to see if it sets/gets right.
>
> Raj
>[/color]

Hallo,

I am coming to this newsgroup with a very strange Problem. I have two c++
files A.cpp and B.cpp....In A.cpp I am creating an openGL window and in
B.cpp I have stored the callback functions. Important is, that the object
A.o has to be created BEFORE B can be compiled. I am sure that sounds
confusing but A.cpp is part of a library that is needed for objects I use in
B (kind of client-server thing). So I cannot include a B.h in the A.cpp. But
B.cpp has an include A.h. I thought of using function pointers and my code
looks something like this:

In A.h the function pointer is defined

A.h

....
extern void (*pDisplay)(voi d); // Definition of a function
pointer pDisplay
....

Because I have to use "extern" (doesnt work other) I have to declare
something to the pointer in A.cpp. I thought of using a dummy funtion:

A.cpp

void dummy(void)
{
cout << I am a stupid dummy function <<;
}

pDisplay = dummy; // assign adress to dummy to pDisplay (NULL doesnt
work)


later I create an open GL window and give the pointer as the display
callback

....
window = glutCreateWindo w(...);
glutDisplayFunc (pDisplay);


But the function that should be the display function is in B.cpp


B.cpp

....
void displayWindow(v oid)
{
// Displaycallback function
}


B is exectueable and has a main function. There...first an object has to be
created that uses a library that contains A.cpp ... then I want to pass
displayWindow to the pointer pDisplay that is defined in A.h

int main (argc, argv)
{

create an object O;

pWindow = displayWindow; // assign displayWindow to the pointer
pDisplay


ok....the code compiled and linked fine. The problem now is, when I execute
it, that the pointer pDisplay keeps the whole time the adress of the dummy
function and not the adress of displayWindow. I thought you can assign
functions to pointers at the runtime somehow. If I assign the adress of
displayWindow to the pointer before the object O is created, I get a memory
error. In my opinion it must have something to do with the keyword "extern"
in the A.h. If I wouldnt need to declare the pointer in the A.cpp then maybe
I wont have this problem. Unhappily I am not very familiar with function
pointers. I used information i found in the net but obviously with less
success. Maybe one of you has a little hint for me or a good advise.

Many thanks
Jan-Henrik

[Jan-Henrik Grobe]

Re: Function pointers

Hallo,

I think I found out why it doesnt work....it has to do with the assignment
of the glut callback function

glutDisplayFunc (mydisplay);

I have the impression, that once assigned, the display function is not
changeable any more....or is there a way...or should I ask in an open GL
newsgroup? ;-)

MfG
Jan-Henrik


"Jan-Henrik Grobe" <jhgrobeNOSPAM@ t-online.de> schrieb im Newsbeitrag
news:d1gp8i$kcj $00$1@news.t-online.com...[color=blue]
> Hallo Ray, others,
>
> thank you for your help...Sadly my problem isnt really away. My code looks
> now somewhat like this
>
> A.h
>
> ...
> typedef void(*MYDISPLAY FUNCPTR)(void); // pointer
> typedef
>
> extern MYDISPLAYFUNCPT R current_display func; // declare new
> FUNCPTR
>
>
>
> MYDISPLAYFUNCPT R getDisplayFunct ion(void); // get/set
> prototypes
>
> void setDisplayFunc( MYDISPLAYFUNCPT R funcIn);
>
>
>
> A.cpp
>
> MYDISPLAYFUNCPT R current_display func = 0; // init current_display
> with a dummy
>
>
>
>
>
> MYDISPLAYFUNCPT R getDisplayFunct ion(void) // get/set
> functions
>
> {
>
> return current_display func;
>
> }
>
>
>
> void setDisplayFunc( MYDISPLAYFUNCPT R funcIn)
>
> {
>
> current_display func = funcIn;
>
> }
>
> ...
>
> //window creation
>
> glutInitWindowP osition(500, 500);
>
> int gmlWin = glutCreateWindo w ("GML-Window");
>
> glutDisplayFunc (getDisplayFunc tion());
>
> ...
>
>
>
> B.cpp (main)
>
>
>
> glutInit(&argc, argv);
>
> cav = new Cav((2*sizeof(f loat)+sizeof(in t));
>
> data = (DemoData*)dave->getSyncBuffer( );
>
> memset(data, 0, 2*sizeof(float) +sizeof(int));
>
> gml = new GML();
>
> setDisplayFunc( wallDisplay); // let current_display pint on
> wallDisplay
>
>
>
> Important to know here is, that for a Cav-Objekt the file A.cpp has to be
> compiled because it is used there. Further its not possible to call
> setDisplayFunc before cav is build because it contains function calls from
> the GML-object gml. The only way it to call setDisplayFunct ion is behind
> the creation of the Cav-Object and the GML-object.
>
> It seems, if I run this code now, that the setDisplayFunc function isnt
> executed properly, because current_display func keeps the value 0 (which
> leads to a NULL display callback error). If I exchange the 0 against the
> dummy func, its always executed. But I wish to use the
> wallDisplay-Function that stands in B.cpp.
>
> The strange thing is, that I can use a similar code under windows
> (VC++.NET 2003) that works well. Somehow it has to work under Linux, too.
>
> Does anyone has any suggestions?
>
> Greetings
>
> Jan-Henrik
>
>
>
>
>
>
> <rajkumar@hotma il.com> schrieb im Newsbeitrag
> news:1111173931 .113829.160140@ z14g2000cwz.goo glegroups.com.. .[color=green]
>> Unfortunately what you have written is pretty vague... and i can only
>> guess what the problem might be....maybe every translation unit is
>> getting its own pDisplay
>>
>> Try this... always use typedefs ... it is much cleaner and easier to
>> understand. Also you will make less typoes
>>
>> typedef void (*MYDISPLAYFUNC PTR)(void);
>>
>>
>> If A builds first.... in some cpp file in A instead of global variable
>> do this
>>
>> MYDISPLAYFUNCPT R current_display func = 0;
>>
>> MYDISPLAYFUNCPT R getDisplayFunct ion()
>> {
>> return current_display func;
>> }
>>
>>
>> void setDisplayFunct ion( MYDISPLAYFUNCPT R funcIn)
>> {
>> current_display func = funcIn;
>> }
>>
>>
>> Now instead of updating a global variable you are calling functions and
>> you can step in the debugger to see if it sets/gets right.
>>
>> Raj
>>[/color]
>
> Hallo,
>
> I am coming to this newsgroup with a very strange Problem. I have two c++
> files A.cpp and B.cpp....In A.cpp I am creating an openGL window and in
> B.cpp I have stored the callback functions. Important is, that the object
> A.o has to be created BEFORE B can be compiled. I am sure that sounds
> confusing but A.cpp is part of a library that is needed for objects I use
> in
> B (kind of client-server thing). So I cannot include a B.h in the A.cpp.
> But
> B.cpp has an include A.h. I thought of using function pointers and my code
> looks something like this:
>
> In A.h the function pointer is defined
>
> A.h
>
> ...
> extern void (*pDisplay)(voi d); // Definition of a function
> pointer pDisplay
> ...
>
> Because I have to use "extern" (doesnt work other) I have to declare
> something to the pointer in A.cpp. I thought of using a dummy funtion:
>
> A.cpp
>
> void dummy(void)
> {
> cout << I am a stupid dummy function <<;
> }
>
> pDisplay = dummy; // assign adress to dummy to pDisplay (NULL
> doesnt
> work)
>
>
> later I create an open GL window and give the pointer as the display
> callback
>
> ...
> window = glutCreateWindo w(...);
> glutDisplayFunc (pDisplay);
>
>
> But the function that should be the display function is in B.cpp
>
>
> B.cpp
>
> ...
> void displayWindow(v oid)
> {
> // Displaycallback function
> }
>
>
> B is exectueable and has a main function. There...first an object has to
> be
> created that uses a library that contains A.cpp ... then I want to pass
> displayWindow to the pointer pDisplay that is defined in A.h
>
> int main (argc, argv)
> {
>
> create an object O;
>
> pWindow = displayWindow; // assign displayWindow to the pointer
> pDisplay
>
>
> ok....the code compiled and linked fine. The problem now is, when I
> execute
> it, that the pointer pDisplay keeps the whole time the adress of the dummy
> function and not the adress of displayWindow. I thought you can assign
> functions to pointers at the runtime somehow. If I assign the adress of
> displayWindow to the pointer before the object O is created, I get a
> memory
> error. In my opinion it must have something to do with the keyword
> "extern"
> in the A.h. If I wouldnt need to declare the pointer in the A.cpp then
> maybe
> I wont have this problem. Unhappily I am not very familiar with function
> pointers. I used information i found in the net but obviously with less
> success. Maybe one of you has a little hint for me or a good advise.
>
> Many thanks
> Jan-Henrik
>
>
>
>
>[/color]