Mailman 3 November 2004 - Cplusplus-sig

problem with overloaded address operator
by Fred Houben Dec. 14, 2004

Dec. 14, 2004

Hello, I'm using boost.python 1.30.2 with Python 2.3 and msvc6. I want to wrap a struct that has an object as data member. The problem is that the address operator has been overloaded and returns a data member address instead of the object address. Personally I think its' bad practise to overload the address operator (especially in this manner) , but it didn't write the code and removing the operator isn't a option. I've simplified the problem into a Hello world example: #include <boost/python.hpp> using namespace boost::python; class Hello { public: char const* greet(){return "Hello, world";} }; class World { public: char const* greet(){return hello.greet();} Hello* operator&() { return &hello; } Hello hello; }; struct Data { World world; }; BOOST_PYTHON_MODULE(world) { class_<Hello>("Hello") .def("greet", &Hello::greet) ; class_<World>("World") .def("greet", &World::greet) ; class_<Data>("Data") .def_readonly("world", &Data::world) ; } this result in the following error: pointer_holder.hpp(177) : error c2440: 'initializing" : cannot convert from 'class Hello *' to 'class World *' I solved the problem by editing pointer_holder.hpp. Replacing Value* p = &*this->m_p; with boost::addressof(*this->m_p);. This way I avoid using the address operator. This works fine, but maybe there's something I'm missing here, any input is welcome. I'm forced to uses boost.python for now 1.30.2, but is this problem solved in other releases? Thanks, Fred Houben

2 8

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

add_property + return value policy
by Neal D. Becker Dec. 2, 2004

Dec. 2, 2004

Is it possible to .add_property with a member function that needs a return_value_policy (e.g, copy_const_reference)?

6 9

pyste + wrapping + overloads
by John Hunter Dec. 2, 2004

Dec. 2, 2004

I am trying to wrap a class method in pyste that has a signature void path_storage::add_poly(const double* vertices, unsigned num, bool solid_path, unsigned end_flags) vertices is a length 2*num array of x,y doubles x0, y0, x1, y1, .... I am using the following wrapper void add_poly_wrapper(agg::path_storage* ps, list vertices, bool solid_path = false, unsigned end_flags = agg::path_flags_none) { size_t N = extract<size_t>(vertices.attr("length")()); double * pverts = new double[2*N]; for (size_t i=0; i<N; i++) { tuple xy = extract<tuple>(vertices[i]); *pverts++ = extract<double>(xy[0]); *pverts++ = extract<double>(xy[1]); } pverts -= 2*N; //rewind ps->add_poly(pverts, N, solid_path, end_flags); } The first problem I've encountered in pyste is that the standard way of specifying wrappers Include("path_storage_wrap.h") PS = Class("agg::path_storage", "agg_path_storage.h") set_wrapper(PS.add_poly, "add_poly_wrapper") doesn't work because there is no PS.add_poly, since pyste defines it with the overload macro BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS(agg_path_storage_add_poly_overloads_2_4, add_poly, 2, 4) How does one specify wrappers for overloaded functions? I don't know enough about the overload macro internals to figure out how to proceed... Thanks, JDH boost_python 1.31.0 with pyste and gccxml-0.6.0

2 1

C++ new/delete with python
by Chris Targett Dec. 1, 2004

Dec. 1, 2004

I've got some code. class test { test(*int); int *objects; }; objects = new int[10]; I want to expose my class `test` to python via Boost, Is there anything special I have to do to get this to expose properly? I'm not too fussed about the constructor but if its workable then thats cool. Is it possible to have a `new` defined array work within python? Thanks

2 1

boost.python tests examples defaults.py
by 陳祈親 Nov. 30, 2004

Nov. 30, 2004

Hi ... I have tried to build the boost.python with VC6 on winXP. I found there may be something wrong with defaults.py. I copy the defaults.cpp and defaults.py on another direction. Then, I issued " python defaults.py". There are run-time erorr about memory. I run the command in debug mode, and found there may be error about std::string argument. However, this run-time error didn't occur under linux. chencc

2 1

Que. C++
by Prashanta Mohanty Nov. 29, 2004

Nov. 29, 2004

dear, i want know the answer: please write a copy constructor for the class given below class one{ char **name; int no_of_name; ........ ....... }; regards prashanta

2 1

Re: new warning using vector_indexing_suite
by Joel de Guzman Nov. 28, 2004

Nov. 28, 2004

Hi, I'm sorry about that. I'll definitely look into this. I'm not sure if it is the correct fix. I do not have access to my workstation right now (working at home), but I'll definitely look into it as soon as I get the chance. Regards, --Joel ------------------------------------------------------------------------ > > Subject: > new warning using vector_indexing_suite > From: > Jeffrey Holle <jeff.holle(a)verizon.net> > Date: > Mon, 22 Nov 2004 13:20:44 -0800 > > > I use linux with gcc v3.4.3. > > I've discovered that compiling my boost.python using application with > 1.32.0, produces very long winded warnings. > > The problem is comparing signed and unsigned longs in > indexing_suite_detail.hpp. > > I've altered this file to avoid these warning, the diff file is attached. > > I don't know if this change is correct. > > I'd appreciate feedback if deemed not so. > > > ------------------------------------------------------------------------ > > 593c593 > < if (from > max_index) // Clip upper bounds to max_index. > --- > >> if ((unsigned long)from > max_index) // Clip upper bounds to max_index. > > 615c615 > < if (to > max_index) > --- > >> if ((unsigned long)to > max_index) >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>C++-sig mailing list >>C++-sig(a)python.org >>http://mail.python.org/mailman/listinfo/c++-sig >> >> >> ------------------------------------------------------------------------ >> >> Subject: >> Re: new warning using vector_indexing_suite >> From: >> Chad Austin <caustin(a)gmail.com> >> Date: >> Mon, 22 Nov 2004 17:59:33 -0600 >> >> >>I just upgraded to Boost 1.32 today and that warning is incredibly >>annoying. I'm surprised the release process didn't catch something >>like that. :( >> >>Chad >> >>On Mon, 22 Nov 2004 13:20:44 -0800, Jeffrey Holle >><jeff.holle(a)verizon.net> wrote: >> >>>I use linux with gcc v3.4.3. >>> >>>I've discovered that compiling my boost.python using application with >>>1.32.0, produces very long winded warnings. >>> >>>The problem is comparing signed and unsigned longs in >>>indexing_suite_detail.hpp. >>> >>>I've altered this file to avoid these warning, the diff file is attached. >>> >>>I don't know if this change is correct. >>> >>>I'd appreciate feedback if deemed not so.

5 9

BUILD
by Stefan Quandt Nov. 25, 2004

Nov. 25, 2004

I try to build an extension with python-debug on Win32. I compiled a debug version of the Python interpreter from source and adjusted PYTHON_ROOT in my Jamrules to it's location. Then I try to build my extendions with bjam -sBUILD=python-debug When bjam tries to link boost_python.dll it complains not finding "python23.lib". As far as I know it should be "python23_d.lib". Or am I missing something? Thanks Stefan

3 16

C++ Python Scope Problems
by Chris Targett Nov. 25, 2004

Nov. 25, 2004

The Code: http://orcon.xlevus.net/PyTest.tar.gz I have included CMake Files and Make Makefiles. Requires boost and python libraries to compile. My Problem. I have my Test C++ module (called 'Test' and exposed it through boost.) In main.py I have created a pure python equlavient to my `Test` module called pyTest. In testScript.py I have a little function (testFunction) that Prints the three varibles (of the object thats passed to it), increments the values by one, then prints them again. Back to main.py. Now when the functions are called to the C++ module, the values are changed by `testFunction` while inside the scope of the function, but when returned back to the default scope (what im assuming its called) the Values get reverted back to their original. When the same stuff is done on the Pure Python equlaivient, the values remain changed when reverted back to the default scope. What I want is, my C++ module to be more like my Python Module, and have the varibles changed by the function. Uh, I hope i make sense.

3 6