[C++-sig] boost::multi_array numpy conversion
I've developed some boost::python code that allows conversion from numpy arrays to boost::multi_array_refs and from boost::multi_array(ref)s to numpy arrays without copying data. It does not deal with lifetime management but nevertheless I've found it very useful. I know pyublas performs a similar function including lifetime management but that is restricted to matrices and vectors. So if anyone is interested I'd be very happy to share it. It does already handle both C and fortran ordered storage and I have in mind to extend it to deal with slices, strides, etc... but have not needed this yet. John. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Py3k unicode to const char* conversion solved (Re: boost::python for Python 3.0)
Hi, After attempted all the hacks come from my mind, I solved the unicode string to const char* conversion problem by simply calling a Python C-API: _PyUnicode_AsString. Since it is start with an underscore, it is not a public API and not documented. But I wonder why it is not documented, as it's really a useful API. PyUnicode manages a PyBytes object as the cached encoded string, and _PyUnicode_AsString will return the lvalue inside the encoded string. So we don't need anything for lifetime management in our code, this API will keep the same semantic as PyString_AsString. Now most of the test cases are passed. Just some corner things remaining, and it seems there is a 2to3 bug caused some doctests syntax not fixed. I'm going to take care of these. Regards, Haoyu Bai ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Py3k unicode to const char* conversion solved (Re: boost::python for Python 3.0)
Haoyu Bai wrote: Hi, After attempted all the hacks come from my mind, I solved the unicode string to const char* conversion problem by simply calling a Python C-API: _PyUnicode_AsString. Since it is start with an underscore, it is not a public API and not documented. But I wonder why it is not documented, as it's really a useful API. PyUnicode manages a PyBytes object as the cached encoded string, and _PyUnicode_AsString will return the lvalue inside the encoded string. So we don't need anything for lifetime management in our code, this API will keep the same semantic as PyString_AsString. That sounds good. I would suggest to get in touch with python-dev people to ask about it (or simply submit an issue at bugs.python.org. They are pretty responsive). Now most of the test cases are passed. Just some corner things remaining, and it seems there is a 2to3 bug caused some doctests syntax not fixed. I'm going to take care of these. Excellent. It seems you are making great progress ! Stefan -- ...ich hab' noch einen Koffer in Berlin... ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] g++ compiler limitations other than -ftemplate-depth-n and -DBOOST_PYTHON_MAX_ARITY ?
Hi, I'm using pyplusplus and Boost.Python to wrap a class where one of the member functions has many (28) arguments, most of them with default values. The wrapping code handles the default arguments with the Py++ "do nothing" approach, i.e. not by using the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS macro. I am using bjam to build my project, and am confident that the code produced by Py++ should compile, because the other member functions with similar (but fewer) arguments and default arguments compile fine. I did have to increase BOOST_PYTHON_MAX_ARITY, and I am sure it is large enough to cover my arguments. I suspect I am running into a compiler limitation because I get a slightly different error message when I remove the -ftemplate-depth-128 flag (the error message appears to be truncated when I have the -ftemplate-depth-18 flag). Here is the essence of the error message, without the -ftemplate-depth-128 flag: --- /data/cmejia/install/boost_1_39_0/boost/python/detail/invoke.hpp: In function `PyObject* boost::python::detail::invoke(... /data/cmejia/install/boost_1_39_0/boost/python/detail/caller.hpp:223: instantiated from `PyObject* ... /data/cmejia/install/boost_1_39_0/boost/python/object/py_function.hpp:38: instantiated from `PyObject* ... dcs.cpp:9: instantiated from here /data/cmejia/install/boost_1_39_0/boost/python/detail/invoke.hpp:75: error: must use .* or ->* to call pointer-to-member function in `f (...)' --- Which doesn't make sense because none of the other code has needed to use .* or ->*. The last 19 arguments to this member function are all doubles, all with default values. If I remove the last 3 doubles from the wrapping code produced by pyplusplus, *and* remove them from the header file I am trying to wrap, I am able to compile successfully. (If I remove them only from my wrapping code, but not from the header file I am trying to wrap, I am unable to compile.) Anyway, this seems to indicate that the compiler is running up against some limit, and I was wondering if there was a flag to set to get past this problem. The current set of compiler flags, from bjam, are "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -DBOOST_PYTHON_MAX_ARITY=40 I am using g++ version 3.4.6 on Red Hat Enterprise Linux WS release 4 (Nahant Update 6). Any information would be appreciated. Thanks in advance, --Chris ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] g++ compiler limitations other than -ftemplate-depth-n and -DBOOST_PYTHON_MAX_ARITY ?
What you describe sounds like GCC is getting confused. It may have run into wrong code, but the error message may be caused by a wrong interpretation of what you wanted to do. The fact that things work if you reduce the number of arguments, and the fact that you had to increase BOOST_PYTHON_MAX_ARITY suggests that perhaps some of the code inside boost.python does not support the arity of your call (and isn't configurable via BOOST_PYTHON_MAX_ARITY, so the compiler couldn't find a matching function for your call. Then, instead of telling you that it couldn't find a match, it thought you may have missed qualification (etc.). However, to substantiate this speculation, I'd need to see the code at the call site. But the source is so noisy due to all the macros that it's impossible to see. Could you send a preprocessed source of the relevant bits ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] const shared_ptr and py++ / boost.python
On Thu, Jun 4, 2009 at 11:37 PM, Nicolas Regnault wrote: > Dear all: > > I am wrapping a library which relies heavily on boost smart pointers (mainly > boost::shared_ptr< T >). In particular, many functions and methods have > signatures like: > > void my_func( const boost::shared_ptr< MyClass > & ); > > Everything works well from within C++ programs. But I encounter a serious > problem with the wrappers I have generated with py++. Indeed, when passing > from python, something which wraps a "shared_ptr< MyClass >" to > my_function(), the code within the function apparently gets a shared_ptr > with a use_count equal to 1 (pointing to the same address), whatever the > use_count of the shared_ptr passed to the function. > > I haven't been able to see what boost.python is doing in between, but > something gets altered. Any idea of what is wrong with the wrappers ? I am pretty sure, there is nothing wrong with the generated code. It is pretty close to the code, you would write. I think it happens, because Boost.Python is able to construct smart pointer class instance( shared_ptr ) from an Python object( which holds C++ class instance ) on the fly. It does so with custom deleter. If your projects works a lot with boost::shared_ptr, may be it makes sense for you to redefine HeldType ( http://www.boost.org/doc/libs/1_39_0/libs/python/doc/v2/class.html#HeldType ). -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
