By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,906 Members | 1,387 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,906 IT Pros & Developers. It's quick & easy.

variable argument list ....

P: n/a
In a vendor file I'm given:

/* start vendor_file.c */

#ifdef __cplusplus
typedef void (*VOIDFUNCPTR) (...); /* pfunc returning void */
#else
typedef void (*VOIDFUNCPTR) (); /* pfunc returning void */
#endif /* __cplusplus */
bool intConnect
(
VOIDFUNCPTR routine, /* routine to be called */
int parameter /* parameter to be passed to routine */
) {}

/* end vedor_file.c */

Now in my_file.cpp

class bar {
public:
bar() {}
void execute() {}
};
class foo
{
bar b;
public:
foo ()
{
//intConnect( &foo::my_isr, (int)this);
intConnect( &foo::my_isr, reinterpret_cast<int>(this)); // get
pointer truncation warnings here.
}
//static void my_isr(foo *ptr, ...) { } // option 1
static void my_isr(...) { } // option 2
};

Consider the lines marked 'option 1 and option 2'. I'd prefer to use
option 1 but option 2 is the only approach that 'compiles'. With
option 2, I might as well get rid of the cast within intConnect.

In any event, with option 1 wont. I get errors:

warning C4311: 'reinterpret_cast' : pointer truncation from 'foo *const
' to 'int'
error C2664: 'intConnect' : cannot convert parameter 1 from 'void
(__cdecl *)(foo *,...)' to 'VOIDFUNCPTR'
This conversion requires a reinterpret_cast, a C-style cast or
function-style cast

I'd prefer option 1 but I'm unsure how could I achieve my objective?

Thanks

Nov 3 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
ma******@gmail.com wrote:
I'd prefer option 1 but I'm unsure how could I achieve my objective?


Neither option will work...you're screwed because the vendor library
isn't compatible with C++ (despite the #defines).

There's no way to extract the args from a function declared
int foo(...). You need at least one named arg. I can't
see a good "legal" way around this. However, I'd venture out
on a limb and suggest that you just cast the option one version
of &my_isr to VOIDFUNCPTR.

Second, there's no guarantee that you can convert a Foo* to int
and back again without trashing it. This can be solved by making
a table that lets you map int to pointers rather than trying to
bash the pointer.
Nov 3 '05 #2

P: n/a
|| Neither option will work...you're screwed because the vendor library

I see. I envisioned that I SOL.

||However, I'd venture out on a limb and suggest that you just cast the
option one version of &my_isr to VOIDFUNCPTR.
I might have tried that..... but can't recall the outcome.

|| Second, there's no guarantee that you can convert a Foo* to int and
back again without trashing it.
You're right. Enough with the 'hacking' i guess.
Thanks Ron

Nov 3 '05 #3

P: n/a
ma******@gmail.com wrote:
|| Neither option will work...you're screwed because the vendor library

I see. I envisioned that I SOL.

||However, I'd venture out on a limb and suggest that you just cast the
option one version of &my_isr to VOIDFUNCPTR.
I might have tried that..... but can't recall the outcome.


Actually what I would suggest is making the function
void myisr(int, ...);

At least that matches how they intend to call it.
Nov 3 '05 #4

P: n/a
|| At least that matches how they intend to call it.
Oddly enough, that was my initial thinking but tried that and got a
complaint from 'gcc' about:
ANSI C++ prohibits convesion from () to (...)
sorry, not implemented: "tree_list" not supported by dump_type

Nov 3 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.