Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Passing a C++ function to wdStart() question

309 views
Skip to first unread message

David

unread,
Jun 30, 2004, 12:23:40 PM6/30/04
to
I am trying to pass a C++ function to wdStart() and am getting the following
error from the complier:

"..\CWatchDog.cpp", line 107: error #4167: argument of type
"void (CWatchDog::*)()" is incompatible with parameter of type
"FUNCPTR"
wdStart(m_WatchDogID, CYCLE_TIME, resetWatchDogTimer,0);
^
1 error detected in the compilation of "..\CWatchDog.cpp".
make: *** [CWatchDog.o] Error 0x1

According to section 7.2.1 of the Programmers guide, to make C++ accessible
to C code, I need to give my C++ function C linkage by prototyping it using
extern "C". This I have done, but I'm still doing something wrong.

Here's my code in CWatchDog.cpp

// My Prototype
extern "C" void resetWatchDogTimer();

// My instruction in a method in CWatchDog.cpp
WDOG_ID m_WatchDogID = wdCreate();
wdStart(m_WatchDogID, CYCLE_TIME, resetWatchDogTimer,0);

// And the method that I wish to attach to the timer
void CWatchDog::resetWatchDogTimer()
{
// do something
}

Can anyone offer advice on how to pass the C++ method to the wdStart()
function?

Thanks in advance to any help you can offer.

Xenos

unread,
Jun 30, 2004, 1:16:56 PM6/30/04
to

"David" <ma...@david-eng.com> wrote in message
news:ddf6334f.0406...@posting.google.com...

> I am trying to pass a C++ function to wdStart() and am getting the
following
> error from the complier:
>
> "..\CWatchDog.cpp", line 107: error #4167: argument of type
> "void (CWatchDog::*)()" is incompatible with parameter of type
> "FUNCPTR"
> wdStart(m_WatchDogID, CYCLE_TIME, resetWatchDogTimer,0);
> ^
> 1 error detected in the compilation of "..\CWatchDog.cpp".
> make: *** [CWatchDog.o] Error 0x1
>
> According to section 7.2.1 of the Programmers guide, to make C++
accessible
> to C code, I need to give my C++ function C linkage by prototyping it
using
> extern "C". This I have done, but I'm still doing something wrong.
>
This has nothing to do with it. extern "C" affect the name-mangling so the
external (linkage) name matches what the C compiler expects. Your problem
is one of typing. FUNCPTR if of the form: "int (*) (...)" your are sending
it a function with a different signature. For one thing, your function
returns void, not int. For another, as the error tells you, you are given
it a pointer to a member, which is completely different. For this to work,
you need to (1) either make it static or define it outside of a class, and
(2) either make it the correct signature or cast it to FUNCPTR. For
example, (FUNCPTR) funcname, or more correctly with C++:
reinterpret_cast<FUNCPTR>(funcname)

Also note, that if your function is accessing other members of the class,
you will have to find another way to do it after you make it static.

Regards,

DrX


aldrin19

unread,
Jul 1, 2004, 4:11:03 AM7/1/04
to
ma...@david-eng.com (David) wrote in message news:<ddf6334f.0406...@posting.google.com>...

I had the same problem with taskSpawn some weeks ago : use a C wrapper
function as WD routine, and pass it a pointer to your CWatchDog
instance as parameter to wdstart, something like that :

void Cwrap( int xx )
{
CWatchDog *wd = (CWatchDog *)xx;
wd->resetWatchDogTimer();
}

...
wd = new CWatchDog(...);
...
wdStart(m_WatchDogID, CYCLE_TIME, Cwrap, (int)&wd);

David

unread,
Jul 1, 2004, 7:55:14 AM7/1/04
to
Thanks DrX,

I wrapped the method in a global C function so I can access the
non-static members of the class.

Regards,
David

"Xenos" <dont.s...@spamhate.com> wrote in message news:<cbusif$mt...@cui1.lmms.lmco.com>...

Xenos

unread,
Jul 1, 2004, 10:14:02 AM7/1/04
to
Glad to help. I would suggest, though, using a static member as the wrapper
instead of a global so as to maintain the encapsulation. static members
decay to "normal" function pointers, not member pointers like non-static
members. I can post an example if you need me to.

DrX

"David" <ma...@david-eng.com> wrote in message

news:ddf6334f.04070...@posting.google.com...

David

unread,
Jul 6, 2004, 10:56:29 AM7/6/04
to
Great suggestion.

Please post an example if you can. I think I can figure it out, but just in case.

Regards,
David

"Xenos" <dont.s...@spamhate.com> wrote in message news:<cc167j$mt...@cui1.lmms.lmco.com>...

David

unread,
Jul 6, 2004, 10:58:35 AM7/6/04
to
Thanks Aldrin,

That is what I ended up doing.

Regards,
David

aldr...@hotmail.com (aldrin19) wrote in message news:<380e665d.04070...@posting.google.com>...

Xenos

unread,
Jul 7, 2004, 8:34:52 AM7/7/04
to

"David" <ma...@david-eng.com> wrote in message
news:ddf6334f.04070...@posting.google.com...
> Great suggestion.
>
> Please post an example if you can. I think I can figure it out, but just
in case.
>
> Regards,
> David
>
something like....


class W {
public:
W() {id = ::wdCreate();}

void start(int delay)
{::wdStart(id, delay, reinterpret_cast<FUNCPTR>(wrapper),
reinterpret_cast<int>(this));}

void stop() {::wdCancel(id);}

protected:
void func() {}

private:
WDOG_ID id;

static void wrapper(W* self) {self->func();}
};

This makes the entire class self-contained. Some considerations:
1. If you make func() virtual, you can create subclasses and overrride the
behavior for different watchdogs. If you do this, make sure to also make
the destructor virtual.
2. Be very careful about owership. For example, if you decide to put the
wdDelete() function in the descructor, and you copy the object, you will be
deleting it twice (be careful of temporaries!). Either give up the
ownership to the new object in you copy constructor and assignment operator,
disallow these functions, or use reference counting to track ownership.
3. Make sure the object "lives" for at least as long as the watch dog is
active. You don't want the watchdog calling functionality for a class
object that has been deconstructed.
4. This kind of trick will work with any library API that allows the client
software to give it a user defined parameter for the provided function
(i.e., taskSpawn).


How this helps,

DrX


David

unread,
Jul 8, 2004, 12:47:17 PM7/8/04
to
Thank you very much for your insights.

I now understand how to deal with these type of functions.

Regards,
David

"Xenos" <dont.s...@spamhate.com> wrote in message news:<ccgqlr$3s...@cui1.lmms.lmco.com>...

0 new messages