Mailman 3 September 2004 - Cplusplus-sig

RE: [C++-sig] Re: Wrapper for exception translation
by Gottfried.Ganssauge＠HAUFE.DE Dec. 13, 2004

Dec. 13, 2004

> > ... > >> > >> > Currently, in order to wrap user defined exceptions you need to > >> > > >> > - allocate a python exception using PyErr_NewException > >> > >> Well, no. I don't see any call to PyErr_NewException in > >> libs/python/test/exception_translator.cpp > > > > Right, you don't need to if you are content with RuntimeError > > exceptions. > > or any other pre-packaged exception type provided by Python. > > > My objective was another one: I wanted to create module exceptions > > that are derived from the python "Exception" class. > >> > >> > This function needs to be parametrized using a specific naming > >> > convention > >> > >> It's not clear to me what you're referring to. Are you > sure you mean > >> "naming convention"? > > Yes. > > From the documentation to PyErr_NewException: > > > > ... The __module__ attribute of the new class is set to > the first part > > (up to the last dot) of the name argument, and the > class name is set to > > the last part (after the last dot). > > ...yeah, that's a naming convention, but I don't see how that affects > the parameterization of any function. It is enforced by PyErr_NewException, so you must follow this convention. On the hand I don't think that any user of boost.python is aware of that convention, so I wanted to codify it within my facility. ... > > What I wanted to achieve was the following: > > Create an instance of a translated_exception_handler<> t > which will be > > registered with the library by calling > > register_exception_translator<>(). > > Sorry to be difficult, but I'm going to contradict you. You didn't > want any of that. What you wanted was to create a new Python > exception type in the module which would correspond to a particular > C++ exception type and would be raised at the boundary with Python > whenever a wrapped function threw the C++ exception. Right? Right. I actually described the way to do it within the current library design. > > > Normally t would be destructed by the end of exception_<>() thereby > > leaving a registration to a non-existing translator - very bad > > karma. > > I don't understand any of this. All you have to pass to > register_exception_translator is a function pointer, and functions > live forever. So where's the lifetime issue? A pointer to a function which has access to python exception instance e. As I didn't want to create separate entities I chose to supply a functor instead which has e as a member variable. > > > Because I didn't like to have an additional container for all > > translated_exception_handler<> instances, I chose to store t within > > e's class dictionary. At that moment it seemed to be the easiest > > way to create a wrapper class using class_<> instead of making a > > true python class by hand (and it even works!). You are right, it > > is way too complex, I will change it to the mechanism I used in > > opaque_pointer_converter. > > I don't know what that is, but before you consider doing something > which is again too complex, please consider: > > template <class E> > struct translate_exception > { > static char const* msg; This would need to be defined somewhere. > static object python_exception_type; ... and this would need to be defined somewhere as well. > > static void handler(E const&) > { > PyErr_SetString(python_exception_type.ptr(), msg.c_str()); > }; > > translate_exception(char const* python_exception_name, > char const* msg_) > { > // need fancier name manipulation here > python_exception_type > = object( > handle<>(PyErr_NewException(name))); > msg = msg_; > register_exception_translator<E>(handler); > } > }; > > > Simple. Yes. ... > > I'll make a redesign ... At times you don't see the forrest, just trees ... I think this time I have a simple facility which is also easy to use (no macros). It could be even simpler with a completely different design but frankly - I have no clue how to implement that: We would need a way to somehow derive (in the python sense) a class_<> from PyExc_Exception (the type of the python Exception class) or any other python class (PyErr_NewException() has a base parameter, which could be used for that). At the same time an exception_translator should be registered for that class_<> which uses PyErr_SetObject() to raise a copy of the exception caught. This would allow us to have true Python exceptions in a pythonic sense directly wrapped around the corresponding C++ exception. > > Thnx for your feedback. > > Cool! Looking forward to it. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com Cheers, Gottfried

3 7

SIGSEGV on extract_pointer
by Itamar Shtull-Trauring Oct. 1, 2004

Oct. 1, 2004

Platform: Redhat 7.3 on x86, gcc 2.96 (yes, it's horrible and ancient), boost 1.31. I have some code that looks like this: extract<Twisted::DatagramProtocol*> pchecker(self.attr("protocol")); if (pchecker.check()) { this->protocol = pchecker(); When running this it gets a SIGSEGV: 0x401eccb5 in boost::python::converter::get_lvalue_from_python () from /usr/local/lib/libboost_python-gcc-mt-1_31.so.1.31.0 (gdb) up #1 0x4027bcf2 in boost::python::converter::extract_pointer<Twisted::DatagramProtocol *>::extract_pointer (this=0xbfffda68, obj=0x87666ac) at /usr/local/include/boost-1_31/boost/python/extract.hpp:203 The code in question being: template <class Ptr> inline extract_pointer<Ptr>::extract_pointer(PyObject* obj) : m_source(obj) , m_result( obj == Py_None ? 0 : (get_lvalue_from_python)(obj, registered_pointee<Ptr>::converters) ) { } Here's the fun part - it does NOT crash when I compile with -fno-inline. My code is perfectly valid, AFAICT - there is a protocol attribute there and it is of the right type. This is part of my C++/Twisted integration project. -- Itamar Shtull-Trauring http://itamarst.org

2 2

Boost.Python and GCC 3.4.2
by Patrick Hartling Sept. 30, 2004

Sept. 30, 2004

I am running into a problem compiling Boost.Python using GCC 3.4.2. I get the following error using Boost.Python from CVS as of today: gcc-C++-action bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o In file included from /home/patrick/src/Boost/boost-cvs/boost/python/object/make_instance.hpp:9, from /home/patrick/src/Boost/boost-cvs/boost/python/object/make_ptr_instance.hpp:8, from /home/patrick/src/Boost/boost-cvs/boost/python/to_python_indirect.hpp:11, from /home/patrick/src/Boost/boost-cvs/boost/python/converter/arg_to_python.hpp:10, from /home/patrick/src/Boost/boost-cvs/boost/python/call.hpp:15, from /home/patrick/src/Boost/boost-cvs/boost/python/object_core.hpp:12, from /home/patrick/src/Boost/boost-cvs/boost/python/object.hpp:9, from /home/patrick/src/Boost/boost-cvs/boost/python/tuple.hpp:10, from /home/patrick/src/Boost/boost-cvs/boost/python/numeric.hpp:10, from /home/patrick/src/Boost/boost-cvs/libs/python/build/../src/numeric.cpp:6: /home/patrick/src/Boost/boost-cvs/boost/python/object/instance.hpp:44: error: a casts to a type other than an integral or enumeration type cannot appear in a constant-expression /home/patrick/src/Boost/boost-cvs/boost/python/object/instance.hpp:44: error: '->' cannot appear in a constant-expression /home/patrick/src/Boost/boost-cvs/boost/python/object/instance.hpp:44: error: `&' cannot appear in a constant-expression In file included from /home/patrick/src/Boost/boost-cvs/boost/python/converter/registry.hpp:9, from /home/patrick/src/Boost/boost-cvs/boost/python/converter/registered.hpp:8, from /home/patrick/src/Boost/boost-cvs/boost/python/object/make_instance.hpp:10, from /home/patrick/src/Boost/boost-cvs/boost/python/object/make_ptr_instance.hpp:8, from /home/patrick/src/Boost/boost-cvs/boost/python/to_python_indirect.hpp:11, from /home/patrick/src/Boost/boost-cvs/boost/python/converter/arg_to_python.hpp:10, from /home/patrick/src/Boost/boost-cvs/boost/python/call.hpp:15, from /home/patrick/src/Boost/boost-cvs/boost/python/object_core.hpp:12, from /home/patrick/src/Boost/boost-cvs/boost/python/object.hpp:9, from /home/patrick/src/Boost/boost-cvs/boost/python/tuple.hpp:10, from /home/patrick/src/Boost/boost-cvs/boost/python/numeric.hpp:10, from /home/patrick/src/Boost/boost-cvs/libs/python/build/../src/numeric.cpp:6: /home/patrick/src/Boost/boost-cvs/boost/python/converter/rvalue_from_python_data.hpp:99: error: '->' cannot appear in a constant-expression /home/patrick/src/Boost/boost-cvs/boost/python/converter/rvalue_from_python_data.hpp:99: error: `&' cannot appear in a constant-expression /home/patrick/src/Boost/boost-cvs/boost/python/converter/rvalue_from_python_data.hpp:99: error: template argument 1 is invalid /home/patrick/src/Boost/boost-cvs/boost/python/converter/rvalue_from_python_data.hpp:99: error: `value' is not a member of `<declaration error>' set -e "g++" -c -Wall -ftemplate-depth-255 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE -g -O0 -fno-inline -fPIC -I"bin/boost/libs/python/build" -I "/usr/local/include/python2.3" -I "/home/patrick/src/Boost/boost-cvs" -o "bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o" "/home/patrick/src/Boost/boost-cvs/libs/python/build/../src/numeric.cpp" The code that GCC is complaining about is the type cast in the last term of the last statement in the following: template <class Data> struct additional_instance_size { typedef instance<Data> instance_data; typedef instance<char> instance_char; static const std::size_t value = sizeof(instance_data) - ((size_t)(&((instance_char *)0)->storage)); }; I haven't run into this problem before, and I am not sure how to go about fixing it (and submitting a patch if appropriate). I did find a semi-related discussion on another mailing list with a reference to the relevant part of the C++ Standard: http://www.cygwin.com/ml/ecos-discuss/2003-02/msg00214.html I have seen reports from other people on this list saying that they are using GCC 3.4 to compile Boost.Python without problems, so I may be doing something wrong. I have attached some simple test code that reproduces the compiler error. Is there a way to work around this, or is it a GCC bug? In case it makes a difference, here are the OS and compiler details: > uname -mrs FreeBSD 5.3-BETA5 i386 > g++ -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 -Patrick -- Patrick L. Hartling Research Assistant, VRAC http://www.137.org/patrick/

3 4

More on documenting boost::python
by Neal D. Becker Sept. 30, 2004

Sept. 30, 2004

I am trying to use epydoc with boost::python. It is almost working now, but I have one problem. Free function docs don't show up. It seems to be related to the fact that they also don't show up in python "help". For example, notice that the function "interleave" shows up in dir(<module>), and if I explicitly ask for help on the function, but not in help(<module>). Anyone ideas? >>> import block_interleaver_wrap >>> dir (block_interleaver_wrap) ['__doc__', '__file__', '__name__', 'block_interleaver', 'deinterleave', 'deinterleave_c', 'interleave', 'interleave_c'] >>> help (block_interleaver_wrap) Help on module block_interleaver_wrap: NAME block_interleaver_wrap - Module for Block Interleavers FILE /disk1/nbecker/shannon2/wrap/block_interleaver_wrap.so CLASSES Boost.Python.instance(__builtin__.object) block_interleaver class block_interleaver(Boost.Python.instance) | Block Interleaver | | Method resolution order: | block_interleaver | Boost.Python.instance | __builtin__.object | | Methods defined here: | | __init__(...) | __init__(size,rows,cols) | Construct a Block Interleaver. | Only full arrays are supported. | @param size: array size | @type size: int | @param rows: rows | @type rows: int | @param cols: cols | @type cols: int | | v(...) | | vinv(...) | | ---------------------------------------------------------------------- | Data and other attributes defined here: | | __instance_size__ = 44 | | ---------------------------------------------------------------------- | Data and other attributes inherited from Boost.Python.instance: | | __dict__ = <dictproxy object> | | __new__ = <built-in method __new__ of Boost.Python.class object> | T.__new__(S, ...) -> a new object with type S, a subtype of T | | __weakref__ = <member '__weakref__' of 'Boost.Python.instance' objects... >>> help (block_interleaver_wrap.interleave) Help on function: interleave(...) interleave(inter,x) Interleave input I{x} using interleaver I{inter}@param inter: stuff

2 3

overloaded constructor, problem with int and bool
by Wolfgang Langner Sept. 30, 2004

Sept. 30, 2004

Hello, I have a C++ class that can be initialized with (double, int and bool). With the following constructor it's not possible to init with a bool value: class_<Value>("Value") .def(init<>()) .def(init<double>()) .def(init<bool>()) .def(init<int>()); Because int is the last entry and it wins. Bool constructor is never called. example: v = Value(False) -> v = Value(0) and int constructor is called Is there a way to get this working ? I tried to change the order and got other strange results. With order .def(init<int>()) .def(init<bool>()) .def(init<double>()); all initializations with int are converted to use the double constructor. v = Value(10) results in a call to the double constructor and Value has the wrong type. Search trough documentation and Mailing list returned no results. Environment: Boost Version 1.31.0, VisualStudio .Net 2003 (VC7.1), Windows XP SP1. (STLPort 4.5.3) bye by Wolfgang

2 2

how to wrap a template function without casting
by Fred Houben Sept. 29, 2004

Sept. 29, 2004

Hello, I'm using a class resource that has a template member function called hasResource. I want to wrap this function with boost.python. I know I can cast hasResource to a function of the desired signature. The following code is an example. #include <boost/python.hpp> using namespace boost::python; using namespace std; class Resource { public: template <typename T> void hasResource( T& value) { } }; BOOST_PYTHON_MODULE(res) { class_<Resource>("Resource") .def ("hasResource", (void (Resource::*)(std::string&)) &Resource::hasResource) ; } The problem is that hasResource has to be able to take about 50 different formal parameters. I don't want to cast all of them. Is it possible to wrap hasResource without having to cast every signature? I hope someone can help me, Fred

2 1

HELP: implicit converter on pointer type failed
by Liwei Peng Sept. 29, 2004

Sept. 29, 2004

Hi, I am using boost python to wrap a C++ class. What I'd like to have is implict type conversion. The following is my code: // C++ part class Circle { public: Circle(float r); float get_area() const; private: float radius; }; class CircleWrapper { CircleWrapper(Circle * c); operator Circle*() const; private: Circle* circle; }; void test_circle(CircleWrapper c); // boost python part implicitly_convertible<Circle*, CircleWrapper>(); // python: c = Cirlce(12.1) test_circle(c) // error message Boost.Python.ArgumentError: Python argument types in test_circle(Circle) did not match C++ signature: test_circle(CircleWrapper) Can someone tell me why 'test_circle()' failed in this case? And how can I make it work? Thanks in advance, Liwei __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

epydoc with boost::python
by Neal D. Becker Sept. 29, 2004

Sept. 29, 2004

I'm trying to use epydoc to doc my boost::python code. I ran into a problem. Here's an example: class_<WrappedClass> (name, "IIR filter", no_init) .def ("__init__", make_constructor (from_range<WrappedClass,ublas::vector<coef_type>,ublas::vector<coef_type> >, default_call_policies(), (arg ("numerator"), arg ("denominator") )), "construct on IIR filter\n" "@param numerator: numerator coeffs\n" "@type numerator: vector\n" "@type denominator: vector" ) .def ("Compute", &compute_wrap<WrappedClass,ublas::vector<input_type>,ublas::vector<output_type> >, (arg ("x")), "@param x: input\n" "@type x: vector\n" "@return: vector" ) ; Running epydoc on this I get errors like this: In iir_wrap.IIR_double.__init__ docstring (line 1): --------------------------------------------------------------------------- - Warning: @param for unknown parameter numerator - Warning: @type for unknown parameter denominator - Warning: @type for unknown parameter numerator epydoc expects python code like this: def ponder(person, time): <<< notice the func args """ @param person: Who should think. @type person: L{Person} or L{Animal} @param time: How long they should think. @type time: C{int} or C{float} """ [...] while I got this: help (iir_wrap.IIR_double) Help on class IIR_double in module iir_wrap: class IIR_double(Boost.Python.instance) | IIR filter | | Method resolution order: | IIR_double | Boost.Python.instance | __builtin__.object | | Methods defined here: | | Compute(...) <<<<< here's the problem | @param x: input | @type x: vector | @return: vector | | __init__(...) | construct on IIR filter | @param numerator: numerator coeffs | @type numerator: vector | @type denominator: vector Any ideas how to fix this?

1 0

make_constructor doc buglet
by Neal D. Becker Sept. 26, 2004

Sept. 26, 2004

The arguments to make_constructor() are not shown in the doc: template <class T, class ArgList, class Generator> object make_constructor(); template <class ArgList, class Generator, class Policies> object make_constructor(Policies const& policies)

2 1

Memory leaks in Python embedded in wxWindows
by Babitski Maxim Sept. 24, 2004

Sept. 24, 2004

>> I am using Python embedded in wxWindows application. And I've found >> memory leaks even in empty applications. There is an example of such >> application below. Without wxWindows there are no memory leaks. > >Why not use wxPython? Because I have C++ program

1 0