ah, great, thanks Bill. yeah, i read the faq about the
standard/non-standard C/C++ stuff. i just wasn't clear on what
'non-standard' C is exactly, although it's not too hard to imagine what is
and what isn't.
and i appreciate the alternate solution - much cleaner. didn't realize SWIG
defines SWIG automatically. thanks!
----- Original Message -----
From: "Bill Clarke" <llib@...>
To: "Wes Hodges" <wes@...>
Sent: Thursday, December 22, 2005 5:36 PM
Subject: Re: [Swig-user] function pointer typedefs
Wes Hodges wrote, On 12/22/05 16:49:
> i'm guessing this is a C/C++ parsing limitation of SWIG, but, just to
> be sure, i'll ask the masters. if i have the following function:
> void [modifier] foo( );
> where [modifier] is __stdcall or APIENTRY or WINAPI (yes, i'm in
> Windows here, and essentially mapping function pointers to OpenGL
> extension functions), and i have the following function pointer
> typedef void ([modifier] * FOO_FUNC_PTR) ( );
> when i SWIG it, SWIG reports a C/C++ syntax error. it doesn't like
> the [modifier] in the typedef. so, parsing limitation? and, if so,
> are there plans to handle it in future versions? i'm guessing no,
> since it's a pretty uncommon typedef...
no, your code is non-standard C/C++. SWIG is only designed to parse
standard C/C++. this is quite a common question, and should be in the
FAQ if it isn't already.
> #ifdef _SWIG
> #undef APIENTRY
> #define APIENTRY
> in my C++ project file, _SWIG is *not* defined (i.e. it builds the
> C++ stuff with APIENTRY set). in my SWIG command line compilation
> statement, _SWIG *is* set (-D_SWIG switch).
this is a good solution, however why not just use #ifdef SWIG? that,
after all, is one of the reasons the macro SWIG is defined by SWIG when
it is parsing an interface file.
often, you don't even need to modify the header. simply create your
interface file as such:
%ignore ...; // whatever you want SWIG to ignore in blah.h