Mailman 3 May 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

Boost Python and Intel C++ 7.1 windows
by Xavier WARIN(Compte LOCAL) - I23 Aug. 16, 2004

Aug. 16, 2004

Hi, While compiling with Intel C++ 7.1 Boost Python , i get this kind of error on class.cpp and a lot of other Boost Python files : C:\boost-1.30.2\boost/type_traits/is_integral.hpp(39): error: class "boost::is_integral<unsigned short>" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) I think that there must be a define that i missed somewhere ! I don't find it Any idea ? Thank you Xavier Warin

2 2

[PATCH] unused variables.
by Giulio Eulisse June 11, 2004

June 11, 2004

Could someone please patch boost/boost.python as follows? Those unused variables generate a lot of warnings when full warning report is used. Thanks. Ciao, Giulio Index: boost/python/class.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/class.hpp,v retrieving revision 1.83.2.2 diff -u -r1.83.2.2 class.hpp --- boost/python/class.hpp 7 Jan 2004 14:08:10 -0000 1.83.2.2 +++ boost/python/class.hpp 25 May 2004 13:35:12 -0000 @@ -556,7 +556,7 @@ template <class Fn, class Helper> inline void def_default( char const* name - , Fn fn + , Fn /*fn*/ , Helper const& helper , mpl::bool_<true>) { Index: boost/python/detail/caller.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/caller.hpp,v retrieving revision 1.21.2.1 diff -u -r1.21.2.1 caller.hpp --- boost/python/detail/caller.hpp 6 Jan 2004 13:08:25 -0000 1.21.2.1 +++ boost/python/detail/caller.hpp 25 May 2004 13:35:12 -0000 @@ -82,7 +82,7 @@ template <class ArgPackage, class ResultConverter> inline ResultConverter create_result_converter( - ArgPackage const& args_ + ArgPackage const& /*args_*/ , ResultConverter* , ... )

2 1

std::string crush
by Vladimir Ignatov June 1, 2004

June 1, 2004

Hello! I am just start learning Boost.Python and faced a strange problem. I need to push some binary data from Python to C++ module. std::string look like a natural way to do it. Unfortunately I can't get this simple stuff working. After several invokes, TestStr() raise the "RuntimeError: unidentifiable C++ exception" which I think is actually a crush (access violation or so). Here is the snippets from my code: -Py----------------------- import dx8 for i in range( 40 ): dx8.TestStr( "a"*96 ) -C++----------------------- void TestStr( std::string s ) { char buf[ 512 ]; ::memcpy( buf, s.data(), 96 ); } BOOST_PYTHON_MODULE(dx8cpp) { def( "TestStr", &TestStr ); } --------------- The looping in this example is essential. Say, after 4 iteration function still work, but 40 iterations kills for shure. If I replace std::string to const char* , like: void TestStr( const char* s ) { char buf[ 512 ]; ::memcpy( buf, s, 96 ); } then problem disappears. Any suggestions are welcomed. My system is Win2000 + Python 2.3 + VS.NET (VC 7.0) + Boost 1.31.0 Vladimir Ignatov

4 5

Boost.Python on MacOS X...at all...
by Nick Bastin June 1, 2004

June 1, 2004

Has anybody succeeded on building Boost.Python on MacOS X at all? It appears that the linker flags are wrong for creating the dylib (c++ -shared is not correct on MacOS X). Also, I get a pile of undefined symbols - when the doc says requires Python 2.2 and later, how far does 'later' go? -- Nick

2 2

pyste defect: expanding typedefs in generated code
by paul.bridger June 1, 2004

June 1, 2004

I've come across a problem with code similar to this: /* Foo.h */ class Foo { private: struct Bar {...}; public: typedef std::vector<Bar> BarList; }; /* MeepMeep.h */ class MeepMeep { public: void f(const BarList&); }; When generating wrappers for MeepMeep using Pyste I get access errors because Pyste expands the BarList typedef to std::vector<Bar>: struct MeepMeep_Wrapper: MeepMeep { void f(const std::vector<Foo::Bar,std::allocator<Foo::Bar> >& p0) }; I cannot suggest a fix because I am not familiar with Pystes innards. What is a shame about this defect is that the workaround requires me to violate one of boost::python's goals of being non-invasive (I must change a private to a public identifier in target code). Is Pyste still under active development? I'm not impatient, just curious. If Pyste is short of active developers I could try to work out a fix for this <cringes>. Paul Bridger

2 3

Building boost.python with non-framework python on MacOS X?
by Nick Bastin May 31, 2004

May 31, 2004

Is it possible to build boost.python with a non-framework python (standard unix install) on MacOS X? I presume that by selecting the darwin tools it also assumes a framework install - is there a toolset on darwin which is more light straight unix (but still works)? -- Nick

2 1

Pyste default module names erroneously include path
by paul.bridger May 30, 2004

May 30, 2004

When I run pyste from a parent directory to the target pyste file, and don't specify the module name (eg. >pyste.py foo/bar.pyste), pyste calculates the module name incorrectly as foo/bar. /* bar.cpp */ BOOST_PYTHON_MODULE(foo/bar) I'm not sure if it matters, but this is done from a python build script: os.system('pyste.py --cache-dir=cache --pyste-ns=__hidden %s' % (filename,)) Paul

2 3

boost::python return_internal_reference
by paul.bridger May 30, 2004

May 30, 2004

Many thanks to David, Jonathon, Niall for previous help. I am wrapping a C++ class Foo, and there is a member function that returns a reference or pointer to something internal to Foo. Clearly, I want to tie the lifetime of the return value (via something like a weakref) to the lifetime of the Foo object. Is 'return_internal_reference<1>' the way to go, where the 1 refers to the class instance? I am pretty sure that this is correct, but I am writing because initially this was not clear to me in the context of member functions (after reading the documentation). All it took was the realisation that the 1st argument to a member is self/this. IMO this is one small area the already very good documentation could be improved: in making this connection explicit. Paul

2 1

C++-sig, bright teen girls
by ritchier＠turnbull.sk.tsukuba.ac.jp May 29, 2004

May 29, 2004

1 0