This may be of no help at all but I see mentions of C++/Python/OO/SWIG and it triggers me to mention something I heard about recently called "PyCXX": http://cxx.sourceforge.net/ I /think/ the idea behind it is to basically make a C++ version of the Python C API. You still do all the wrapping yourself, but it's much less painful.
--bb On 4/20/07, Matthieu Brucher <[EMAIL PROTECTED]> wrote: > > > Doing the wrapping in an object oriented way is difficult, and maybe > > not that useful. This does not prevent the API exposed to python to be > > OO, of course. > > > I have some difficulties to do this in an automated way... > I'm trying now to make a derived object from my function, without templates > and, I'm hoping so, with a correct interface i.e. double + 2*int to save > make the conversions with numpy arrays. > > > > That works great for C then, not that well for C++... > > Well, this is an inherent problem of C++ when you try to use it from > > other languages, but let's not start this (again :) ), > > > :D > > > > The example shows basic wrapping, and some facilities provided by > > numpy to help. Again, ctype is pretty efficient as long as you do not > > need to do convertion. If you call it thousand of times, it will be > > slow, but this is more or less inherent to python (function calls are > > nowhere near as fast as in a compiled language, at least for now). > > > It's for optimization, so the function will be called several hundreds of > times, I suppose, and I tried porting the whole function to Python, but I'm > not sure that the Python version behaves like the C++ version - the results > are not identic, so... -, thus the wrapping. > > > SWIG may be better in your case because it is aware of C++ classes, > > and is *compiling* an extension, whereas ctypes does not compile > > anything. This means that you do not have to care about binary > > interfaces problemes between foreign object codes. SWIG parses a prett > > good deal of C++, and is aware of classes (template is another matter, > > obviously). numpy sources contain swig code to process automatically > > numpy arrays (that is convert C representation of a numpy array to a > > simple C array and vice et versa), if I remember correctly. > > > Yes, I will try to use this solution, I have trouble figuring how passing > the output numpy array, Bill Baxter asked the same question today, at > exactly the same time ;) Well, I saw on the docs that such arrays must be > passed to the function, and already allocated, and that is a problem for > me... > > > There is also boost.python, but I don't know if its situation towards > > numpy array has changed (eg there was some code lying around to > > represent numpy arrays in C++). > > > That will be my next quest during the summer ;) > > > If I were you, and if there are only a few classes and a few member > > functions, I would try the C wrapper called from python first. > > > It's only one class and one method + the constructor. Not much but I'm a > real beginner in that domain. True, I could use the C API directly... > > > Matthieu > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > > _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion