[C++-sig] problems with typedef void *
Howdy!
I'm wrapping a C libary with Boost Python and having a really difficult time
with void * typedefs. For example, here's a typedef and the function header
that uses it:
typedef void * EmoEngineEventHandle;
EmoEngineEventHandle EE_EmoEngineEventCreate();
And my undoubtedly overly simplistic wrapper for the function:
def("EE_EmoEngineEventCreate", EE_EmoEngineEventCreate);
The compiler complains with lots of similar messages:
1>C:\boost_1_45_0\boost/python/detail/caller.hpp(223) : error C2027: use of
undefined type
'boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning'
1>with
1>[
1>T=result_t
1>]
1>C:\boost_1_45_0\boost/python/detail/caller.hpp(200) : while
compiling class template member function 'PyObject
*boost::python::detail::caller_arity<0>::impl::operator
()(PyObject *,PyObject *)'
1>with
1>[
1>F=void (__cdecl *)(void),
1>Policies=boost::python::default_call_policies,
1>Sig=boost::mpl::vector1
1>]
There are also functions that pass these typedefs as args, and I expect I'll
have problems with these, too. i.e.:
void EE_EmoEngineEventFree(EmoEngineEventHandle hEvent);
There are a *lot* of these functions in the library I'm wrapping that use
and return void * typedefs. Is there a way to translate the typedefs to get
all of my function wrappers to pass them properly? Failing that, how do I
modify my wrappers to support the typedefs?
Much obliged,
Jacob Davis
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] problems with typedef void *
On 12/12/2010 01:02 PM, Jacob Davis wrote:
Howdy!
I'm wrapping a C libary with Boost Python and having a really difficult
time with void * typedefs. For example, here's a typedef and the
function header that uses it:
typedef void * EmoEngineEventHandle;
EmoEngineEventHandle EE_EmoEngineEventCreate();
There are also functions that pass these typedefs as args, and I expect
I'll have problems with these, too. i.e.:
void EE_EmoEngineEventFree(EmoEngineEventHandle hEvent);
There are a *lot* of these functions in the library I'm wrapping that
use and return void * typedefs. Is there a way to translate the typedefs
to get all of my function wrappers to pass them properly? Failing that,
how do I modify my wrappers to support the typedefs?
Hopefully someone else will have a more elegant solution, because
everything I can think of is pretty ugly. Boost.Python is totally based
on templates, and the complete lack of truly distinct types is a big
problem, because it has no way to know what Python types to map to when
all the C++ types are indistinct.
I think you'll want to define a custom wrapper class for each of these
typedefs with a distinct type. From your example, it looks like many of
these might be similar enough that you could use a template:
enum VoidTag { EmoEngineEventHandleTag, ... };
template
struct VoidWrapper : private boost::noncopyable {
VoidWrapper() : p(ctor()) {}
~VoidWrapper() { dtor(p); }
void * p;
};
typedef VoidWrapper<
EmoEngineEventHandleTag,
&EE_EmoEngineEventCreate,
&EE_EmoEngineEventFree
> EmoEngineEventHandleWrapper;
-
Now, for all the other (non-constructor/destructor) functions that take
these, you'll need to write a function wrapper that takes arguments by
the wrapper classes, calls the C function, and returns using the wrapper
classes (you'll have to think about ownership semantics in that case, of
course). Then you can use Boost.Python to wrap the wrapper functions.
You might be able to use templates for the function wrappers too, if
certain signatures are common enough.
You could also approach this by writing custom Boost.Python call
policies, I think, but that would require a lot of advanced Boost.Python-fu.
Finally, I wouldn't normally recommend SWIG, because I think
Boost.Python is generally much better, especially for wrapping C++ code.
But in this case, since you're wrapping pure C using a lot of opaque
pointers, SWIG's approach might be a better fit, since its code
generation naturally considers everything an opaque pointer. If you
don't have to use Boost.Python for other reasons, it might be worth a
look, at least.
Good luck!
Jim Bosch
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] problems with typedef void *
On 12/12/2010 04:02 PM, Jacob Davis wrote:
Howdy!
I'm wrapping a C libary with Boost Python and having a really
difficult time with void * typedefs. For example, here's a typedef and
the function header that uses it:
typedef void * EmoEngineEventHandle;
EmoEngineEventHandle EE_EmoEngineEventCreate();
And my undoubtedly overly simplistic wrapper for the function:
def("EE_EmoEngineEventCreate", EE_EmoEngineEventCreate);
The compiler complains with lots of similar messages:
1>C:\boost_1_45_0\boost/python/detail/caller.hpp(223) : error C2027:
use of undefined type
'boost::python::detail::specify_a_return_value_policy_to_wrap_functions_returning'
There are a couple of issues with your approach. Note that the line
above is a trick to pass a message through a (very noisy) compiler
error. The "specify_a_return_value_policy..." piece above is telling you
that you can't wrap a function returning a void pointer without
explicitly telling boost.python what to do with the pointer. Normally it
would attempt to pass by-value, but that obviously doesn't work (you
can't dereference a void pointer !).
But, if you want to pass by-reference, how should the pointer be treated
? Who owns the data ?
More importantly, you don't use a strong type system in your API, since
"types" are aliasing void pointers. Thus, the compiler can't help you
distinguish e.g. function overloads, and there is no way to
auto-generate a type registry.
You may wrap your API with a C++ wrapper, though I honestly doubt this
is practical. In fact, I'm in doubt that boost.python is the right
choice for your Python wrapping effort. Have you considered alternatives ?
Stefan
--
...ich hab' noch einen Koffer in Berlin...
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
