Re: [C++-sig] problems with typedef void *
On Sun, Dec 12, 2010 at 3:04 PM, Jim Bosch wrote: > 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: > > [snip] > > 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. > [snip] > > 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. > > Thanks Jim! I kind of expected that I would need to do wrapper classes and functions, but was hoping it wouldn't quite come to that. I Niall's patch doesn't work out well, I might just do this. As for SWIG, I considered it, but chose Boost for the sake of learning a bit more about it. Maybe it would be wise to just scrap it and go with SWIG though. - Jacob ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] problems with typedef void *
On Tue, Dec 14, 2010 at 11:03 PM, Jacob Davis wrote: > > > On Sun, Dec 12, 2010 at 3:04 PM, Jim Bosch wrote: > >> 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: >> >> [snip] > >> >> 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. >> > [snip] > >> >> 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. >> >> > Thanks Jim! I kind of expected that I would need to do wrapper classes and > functions, but was hoping it wouldn't quite come to that. I Niall's patch > doesn't work out well, I might just do this. As for SWIG, I considered it, > but chose Boost for the sake of learning a bit more about it. Maybe it would > be wise to just scrap it and go with SWIG though. > > >From my experience, if you have to expose a C API and you have a dynamic library, the best way to access it is to use ctypes (which comes with Python). If the API is pretty complex, then you can create a facade to it, but already in Python. ctypes module removes a huge amount of headaches. HTH ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] problems with typedef void *
On 14 Dec 2010 at 14:07, Jacob Davis wrote: > I read through the thread back when I started work on this problem, but > figured if it had been scrubbed out it might not be wise to use it. I'll go > back and check it out soon, though. Trampoline types are a very commonly used idiom in C++ metaprogramming. They let you work around pre-C++0x limitations. > The last I saw on the subject, void > pointers were supposed to "just work", but I wonder if they "just work" > outside the context of a typedef obfuscation. If this doesn't work out, I'll > probably just do an extra layer of wrapping as Jim suggested. There is absolutely no reason why you can't declare all your typedefed void * as opaque pointers and get to work. The only problem will be that BPL won't know what to do with them (as they all look like void * and therefore are indistinguishable) and therefore can't touch them in any way except to pass them around unmodified. This probably won't be much use to you. I might add that another - and better solution - is to modify the C library to use proper opaque structures like you're supposed to in C rather than void * for everything. I would assume that below the header API its source is casting them to internal structures anyway, so you should be able to modify its header to use declared but not defined structs with the names that it's typedefing them to e.g. typedef void *EmoEngineEventHandle; ... this goes to: struct EmoEngineEventHandle_t; typedef struct EmoEngineEventHandle_t *EmoEngineEventHandle; Theoretically this should let you compile your C library just fine if it is indeed casting to internal structs. Even if it doesn't, it would be very easy to fix. It isn't 100% legal C or C++ though as it's type punning. However I can't think of a compiler which won't allow it. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] expose functor?
Suppose I have a functor, e.g.:
template
struct mag_sqr1 {
F operator() (F z) {
return (z * z);
}
};
Any way to expose this a a python function?
def ("mag_sqr", ???);
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
