Mailman 3 August 2003 - 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

RE: [C++-sig] Converting CString to/from std::string
by Kirsebom Nikolai Sept. 25, 2003

Sept. 25, 2003

-----Original Message----- From: Ralf W. Grosse-Kunstleve [mailto:rwgk@yahoo.com] Sent: 27. mai 2003 08:46 To: c++-sig(a)python.org Subject: Re: ÆC++-sigÅ Converting CString to/from std::string --- Nikolai Kirsebom <nikolai(a)micon.no> wrote: > I have a rather large set of C++ classes I want to make accessible > (initially only parts of some of the classes) from Python. I cannot > change the classes as they are defined and used throughout a large > application. Some of the methods take CString as parameters and others > return CString values. > > Does anyone have suggestion on how I can convert these parameters so > that I can use Boost.Python to generate the wrapper code. What do you want your CStrings to be in Python? Regular Python strings? If you think "yes" remind yourself that Python strings are immutable. I.e. if you have function signatures involving non-const references or pointers to CString as arguments or return values the mapping from C++ CStrings to Python strings will not work very well. More depending on your response. Ralf Some time ago I made a 'socket based' system (using BISON/FLEX for parsing) where I expose C++ objects to python. In this system CStrings are regular Python strings. So as an example I can write: --------------------------------------------- C++: class IF { CString MenuText; CString GetHelpText(); int SetHelpText(CString s); }; In Python: o = IF() # Behind the 'curtains' create a 'link' to a C++ object print o.MenuText s = o.GetHelpText(o.MenuText + "some text") ---------------------------------------------- So I would like something similar. I'm very new to the Boost system and do not really have experience in C++ Template development so I find the Reference Manual somewhat difficult to understand. This may explain if I request 'dead easy' or 'impossible' things. Thanks for any help Nikolai

4 6

Some patches to make the "Automatic PyUnicode to 'const char*'" possible, and make __stdcall function bindable
by Lijun Qin Sept. 13, 2003

Sept. 13, 2003

Hi, I have some patches to make the "Automatic PyUnicode to 'const char*'" possible (please see http://mail.python.org/pipermail/c++-sig/2003-August/004997.html for details) and make the export of '__stdcall' function possible. In addition to the changes in the boost.python source, the file <boost/type_traits/detail/is_mem_fun_pointer_impl.hpp> also need to changed to add some lines to match the (__stdcall T::*) functions, many lines in this file seemed were generated by the compile through defining something I don't known, maybe Mr. David Abrahams can make these changes (it exists in another library) #ifdef BOOST_MEM_FN_ENABLE_STDCALL template <class R, class T > struct is_mem_fun_pointer_impl<R (__stdcall T::*)() > { BOOST_STATIC_CONSTANT(bool, value = true); }; ... ... lots of lines similar to this ... #endif Lijun Qin http://www.solidshare.com --------------------------------------------------------------------------- p.s. Use the convert_unicode_policy like this: .def("SetWindowText", convert_unicode_policy<some_other_policy_you_needed<> >()) Then you can pass both PyString and PyUnicode to your method, without the explicit str() call.

2 2

Adding __len__ to range objects
by Raoul Gough Sept. 10, 2003

Sept. 10, 2003

I recently wanted to know how many items were in a C++ vector, which I had only exposed to Python via iterator pairs (boost::python::range). Currently, len(range_object) doesn't work because range doesn't provide a __len__ method, but it isn't hard to add this. I did the following in d:/CVS/boost/boost/boost/python/object/iterator.hpp: in template <...> struct iterator_range, add typename std::iterator_traits<Iterator>::difference_type distance () const { return std::distance (m_start, m_finish); } in template <...> object demand_iterator_class (...) return class_<range_>(name, no_init) .def("__iter__", identity_function()) .setattr("next", next_function) .def("__len__", &range_::distance) ; and everything worked OK. This seems to me like a useful addition - any comments? If it seems sensible, maybe David Abrahams could add something similar to the CVS? -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta

3 35

Patch to add thread support to invoke function.
by Lijun Qin Sept. 5, 2003

Sept. 5, 2003

Hi, I have made some changes to the invoke.hpp file, to add Py_UNBLOCK_THREADS result = f(...); Py_BLOCK_THREADS pair, this is need for too reasons: First, if the f(...) is a lengthy operation, it'll block all Python code to execute, this is not good, second, if f(...) function call some functions that will acquire the python global lock, it'll deadlock, one example is the COM inproc server using Pythoncom22.dll, every COM interface method will first call PyEval_AcquireThread, but the global lock has been held, so deadlock occur. Lijun Qin http://www.solidshare.com

2 4

RE: undefined symbol "typeinfo for boost::python::instance_holder " under Linux/RH9
by Langston, Matthew David Sept. 4, 2003

Sept. 4, 2003

Hi Dave, Under Linux I simply did a bjam "-sTOOLS=gcc", which created boost/libs/python/build/bin-stage/libboost_python.a which bjam appears to have copied (based on file sizes) from boost/libs/python/build/bin/libboost_python.a/gcc/release/runtime-link-dynamic/libboost_python.a So, I assume bjam built everything properly. What else to try? Are you saying that statically linking to libboost_python.a on linux/gcc should work? I am using boost 1.30.0, so would upgrading to 1.30.2 maybe help? -Matt "Langston, Matthew David" <langston at SLAC.Stanford.EDU> writes: > Why doesn't statically linking to Boost.Python work under Linux/gcc? > Thank you for your help. Not using bjam is usually the explanation for this sort of problem, but it could just as easily be a compiler bug. How are you doing the build? Did you build a static version of Boost.Python to link to (libboost_python.a)?

2 2

STLPort problems
by Mike Thompson Aug. 31, 2003

Aug. 31, 2003

I'm getting compile time errors when building Boost.Python using STLport. I'm using the following combination: Python 2.3 Boost 1.30.2 STLport 4.5.3 VC++ 6 on Windows XP Pro These compile time problems (see below) do NOT happen if I remove use of STLport and just use the VC++6 standard libs. When I do that I get a clean compile. To get around the problem, I have tried overnight cvs and I've also tried using the VC6 projects supplied in the distribution. Exactly the same problem each time. No difference. The compile errors occurs on some, but not all, files. Here are the first few error lines when I use 1.30.2 and the supplied VC6 projects: --------------------Configuration: boost_python - Win32 Debug-------------------- Compiling... builtin_converters.cpp C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\../include/new(35) : warning C4290: C++ Exception Specification ignored C:\MEDIAWISE\LIBS\STLPORT-4.5.3\STLPORT\wrap_std/complex(41) : error C2039: 'tan' : is not a member of 'std' C:\MEDIAWISE\LIBS\STLPORT-4.5.3\STLPORT\wrap_std/complex(41) : error C2873: 'tan' : symbol cannot be used in a using-declaration C:\MEDIAWISE\LIBS\STLPORT-4.5.3\STLPORT\wrap_std/complex(42) : error C2039: 'tanh' : is not a member of 'std' C:\MEDIAWISE\LIBS\STLPORT-4.5.3\STLPORT\wrap_std/complex(42) : error C2873: 'tanh' : symbol cannot be used in a using-declaration ../../../../boost/python/converter/builtin_converters.hpp(106) : error C2146: syntax error : missing ',' before identifier 'LONG_LONG' ../../../../boost/python/converter/builtin_converters.hpp(106) : error C2065: 'LONG_LONG' : undeclared identifier ../../../../boost/python/converter/builtin_converters.hpp(106) : error C2059: syntax error : '>' ../../../../boost/python/converter/builtin_converters.hpp(106) : error C2143: syntax error : missing ';' before '{' ../../../../boost/python/converter/builtin_converters.hpp(106) : error C2146: syntax error : missing ',' before identifier 'LONG_LONG' ../../../../boost/python/converter/builtin_converters.hpp(106) : error C2144: syntax error : missing ',' before type 'const int' ../../../../boost/python/converter/builtin_converters.hpp(106) : error C2990: 'to_python_value' : non-template class has already been defined as a template class ../../../../boost/python/converter/builtin_converters.hpp(33) : see declaration of 'to_python_value' ../../../../boost/python/converter/builtin_converters.hpp(106) : error C2913: explicit specialization; 'struct boost::python::arg_to_python boost::python::arg_to_python' is not a class template ../../../../boost/python/converter/builtin_converters.hpp(106) : see declaration of 'arg_to_python' ../../../../boost/python/converter/builtin_converters.hpp(107) : error C2146: syntax error : missing ',' before identifier 'LONG_LONG' ../../../../boost/python/converter/builtin_converters.hpp(107) : error C2059: syntax error : '>' ../../../../boost/python/converter/builtin_converters.hpp(107) : error C2143: syntax error : missing ';' before '{' ../../../../boost/python/converter/builtin_converters.hpp(107) : error C2146: syntax error : missing ',' before identifier 'LONG_LONG' ...... etc I will now delve deeper, but wanted to make sure I'm not making an obvious mistake. To build, I'm using a batch file like this: rem Get environment right for compiler -- comment out after first run rem "C:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.BAT" rem Setup for Boost.Python set PYTHON_ROOT=C:\Python23 set PYTHON_VERSION=2.3 rem Setup for Boost 'toolset' set STLPORT_PATH=C:\proj\libs set STLPORT_4.5.3_PATH=C:\proj\libs\STLport-4.5.3 set STLPORT_VERSION=4.5.3 bin.ntx86\bjam "-sTOOLS=msvc-stlport" -- Mike

2 12

Unresolved external symbols with Visual C++ 7.0 and 7.1
by Patrick Hartling Aug. 30, 2003

Aug. 30, 2003

I am having a really hard time trying to get my Boost.Python-based module to compile on Windows using Visual C++ 7.0 or 7.1. Everything is fine with GCC and MIPSpro, but with Visual C++, I get linker errors about three missing symbols. I have attached a file that demonstrates the linker error, but it only shows one of the unresolved symbols: test.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class boost::python::api::object __cdecl boost::python::objects::function_object(class boost::function2<struct _object *,struct _object *,struct _object *,class std::allocator<class boost::function_base> > const &,unsigned int,struct std::pair<struct boost::python::detail::keyword const *,struct boost::python::detail::keyword const *> const &)" (__imp_?function_object@objects@python@boost@@YA?AVobject@api@23@ABV?$function2@PAU_object@@PAU1@PAU1@V?$allocator@Vfunction_base@boost@@@std@@@3@IABU?$pair@PBUkeyword@detail@python@boost@@PBU1234@@std@@@Z) referenced in function "class boost::python::api::object __cdecl boost::python::detail::make_function_aux<void (__cdecl*)(struct _object *),struct boost::python::default_call_policies,struct boost::python::detail::args_from_python,struct boost::mpl::list2<void,struct _object *>,struct boost::mpl::int_<0> >(void (__cdecl*)(struct _object *),struct boost::python::default_call_policies const &,struct boost::python::detail::args_from_python const &,struct boost::mpl::list2<void,struct _object *> const &,struct std::pair<struct boost::python::detail::keyword const *,struct boost::python::detail::keyword const *> const &,struct boost::mpl::int_<0>)" (??$make_function_aux@P6AXPAU_object@@@ZUdefault_call_policies@python@boost@@Uargs_from_python@detail@34@U?$list2@XPAU_object@@@mpl@4@U?$int_@$0A@@84@@detail@python@boost@@YA?AVobject@api@12@P6AXPAU_object@@@ZABUdefault_call_policies@12@ABUargs_from_python@012@ABU?$list2@XPAU_object@@@mpl@2@ABU?$pair@PBUkeyword@detail@python@boost@@PBU1234@@std@@U?$int_@$0A@@92@@Z) If I defined and expose methods from the class to Python, I could get the number of unresolved symbols goes up to three. However, I suspect that if I can figure out what is going wrong that causes the above error, I will be able to fix the other two unresolved symbols as well. I based my compiler and linker commands on the output from running jam with the -n option, as suggested by the documentation: cl /nologo /TP /Zm800 /GR /GX /Z7 /Od /Ob0 /GX /GR /MDd /IC:\cygwin\home\patrick\bpl-vc71\include /IC:\Python22\include /I. /c test.cpp link /nologo/DEBUG /subsystem:console /incremental:no /dll /out:test.pyd /implib:test.lib /LIBPATH:C:\cygwin\home\patrick\bpl-vc71\lib /LIBPATH:C\Python22\libs boost_python.lib test.obj What I am missing or doing wrong? -Patrick -- Patrick L. Hartling | Research Assistant, VRAC patrick(a)vrac.iastate.edu | 2624 Howe Hall: 1.515.294.4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ #include <boost/python.hpp> using namespace boost::python; template<typename DATA_TYPE> class Test { public: Test() { } }; BOOST_PYTHON_MODULE(test) { class_< Test<float> >("Testf", init< >()); }

2 2

undefined symbol "typeinfo for boost::python::instance_holder" un der Linux/RH9
by Langston, Matthew David Aug. 30, 2003

Aug. 30, 2003

I've built a Boost.Python module (from boost 1.30.0) that I want to link statically against libboost_python.a. This works fine under Windows and cl, but doesn't work under Linux (RedHat 9) and gcc 3.2.2. When I import my statically linked module under python (i.e. "import ntuple"), I get this error: ImportError: /work/langston/projects/build/NTuple_static/NTuple/.libs/ntuplemodule.so: undefined symbol: _ZTIN5boost6python15instance_holderE The gcc demangler (c++filt) says this symbol is: "typeinfo for boost::python::instance_holder" FYI, I am defining BOOST_PYTHON_STATIC_LIB when try to statically link to Boost.Python. Also, when I dynamically link to Boost.Python everything works fine (on both Windows and Linux). Why doesn't statically linking to Boost.Python work under Linux/gcc? Thank you for your help. Warmest regards, Matt -- Matthew D. Langston, Ph.D. GLAST, Stanford Linear Accelerator Center langston(a)SLAC.Stanford.EDU

2 1

Pyste - wrong code generation - maybe
by Roman Yakovenko Aug. 28, 2003

Aug. 28, 2003

Hi. I use Pyste from CVS. I use VC++ 6.0, SP5 The following code produce error on my machine. ( Pyste generates code like this on generating wrappers (in my case). ) I don't know whether it ligal error from compiler or not. I think Dave Abrahams will give the answer in a second. If this legal error then we need to fix pyste. Also I think I can try to fix this. namespace ns { class A { public: virtual int s(){ return 1; } }; } class B : public ns::A { public: virtual int s() { return ns::A::s(); } //<-- error must be A::s }; Roman

2 1