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

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

indexing_v2 status update
by Raoul Gough Jan. 25, 2004

Jan. 25, 2004

Here's a status report on the indexing_v2 work I've been doing: o I've improved the handling for containers of shared_ptr's, so that sorting and searching automatically do the right indirection. o Fixed various layout and naming convention issues o container_proxy is now strongly exception safe (commit or rollback) o The container_proxy Generator parameter now works even on MSVC6 o I've added a Flags parameter to allow expensive features (in terms of object code size) to be selectively disabled. o I've added convenience templates for use without partial template specialization support (vector_suite, map_suite, etc.) These last two points bring the interface a little closer to what Joel de Guzman had originally, although the flags that he used were passed separately as individual bool parameters instead of as flag bits. He certainly wasn't kidding about the extra effort in supporting MSVC6. So as far as I know, there is no outstanding coding work remaining for the current level of functionality. I'm now updating the documentation to reflect the recent changes, and then the suite, in my opinion, will be ready for release. One possible extension I've been thinking about, as suggested by Ralf W. Grosse-Kunstleve, is the idea of allowing construction of a container from a Python iterable object: e.g. v = Vector ([1,2,3]) The ideal way to do it would be to massage the single input parameter into two C++ iterators that could be passed to the templated vector constructor, but I haven't looked far enough into the constructor dispatching internals to know how to do this, or even if it is possible. The problem, AFAICS, would be knowing when to select that overload of the constructor and when not to, and how/where to insert the necessary code to create the two iterators from the single Python object. Any advice would be appreciated. This might also be significant for another of Ralf's suggestions - pickling support. So I have two loosely related questions - what do people thing about including the current indexing_v2 suite in release 1.31, and should I try adding the iterator-based constructor support? -- Raoul Gough. export LESS='-X'

7 48

class_<>::add_property() on CVS-HEAD
by Jonathan Brandmeyer Jan. 3, 2004

Jan. 3, 2004

The following example demonstrates a method of using add_property that works with Boost.Python 1.30 but not CVS-HEAD (from sourceforge CVS). The example posted is somewhat useless as-is, but demonstrates something that I started using for properties with non-trivial accessors. Is there a replacement for this functionality? Thanks, Jonathan Brandmeyer -------------------------------------------------------------- #include <boost/python.hpp> namespace test { // Hmm. return_internal_reference<>() wants to wrap a real class. class ret_type { public: double i; }; class crash_me { private: ret_type i; public: ret_type& get_i() { return i; } }; } BOOST_PYTHON_MODULE( crash_test) { using namespace boost::python; class_< test::ret_type>( "ret_type") .def_readwrite( "i", &test::ret_type::i) ; class_< test::crash_me> crash_me_wrapper( "crash_me"); crash_me_wrapper .def( "get_i", &test::crash_me::get_i , return_internal_reference<>()) ; // The following works under Boost 1.30, but not CVS-HEAD // (sourceforge repository). crash_me_wrapper.add_property( "i", crash_me_wrapper.attr("get_i")); } -------------------------------------------------------- Testing with G++ 3.3.2 (Debian) results in the following error using CVS-HEAD: /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/class.hpp: In member function `boost::python::api::object boost::python::class_<T, X1, X2, X3>::make_fn(const F&) [with F = boost::python::api::proxy<boost::python::api::attribute_policies>, T = test::crash_me, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]': /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/class.hpp:365: instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::add_property(const char*, Get) [with Get = boost::python::api::proxy<boost::python::api::attribute_policies>, T = test::crash_me, X1 = boost::python::detail::not_specified, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' crashme.cpp:38: instantiated from here /home/jonathan/src/boost-CVS-HEAD/boost/boost/python/class.hpp:429: error: no matching function for call to `get_signature(const boost::python::api::proxy<boost::python::api::attribute_policies>&, test::crash_me*)'

2 3

Sharing Singleton instances across boost.python extension modules
by Joel Gerard Jan. 2, 2004

Jan. 2, 2004

Hi all, How do I share singleton instances across extension modules in Windows? For instance, if I have an instance of a memory manager in one DLL, how do I use the same memory manager in the other? I realise this is a big question, but any links, references etc would be appreciated. Is it even possible? Joel ===== __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

2 1

IntWrapper.hpp in indexing_suite
by Niall Douglas Dec. 31, 2003

Dec. 31, 2003

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Firstly, let me confirm I have this right: IntWrapper is converted into an int by bpl using the operator boost::shared_ptr<IntWrapper>() const yes? Or is it the implicitly_convertible? If it is the latter, why do we need the shared_ptr<> operator? Anyway I came up with the below by basically following the testlinear.cpp example but unfortunately it complains "TypeError: No to_python (by-value) converter found for C++ type: class boost::python::indexing::iterator_pair<class CArrayMember<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > *>". The code I used was: >>> from TestCArrays import * >>> a=MyList() >>> b=a.getData() I don't get why it's failing to find the conversion with mine whereas it works with the test :( Any help much appreciated. Cheers, Niall - --- cut --- #include <boost/python.hpp> #include <boost/python/suite/indexing/container_suite.hpp> #include <boost/python/suite/indexing/iterator_pair.hpp> #include <boost/python/suite/indexing/container_proxy.hpp> #include <string> class MyList { std::string *array; public: MyList(); std::string *getData() { return array; } }; MyList::MyList() { static std::string data[]={ std::string("Niall"), std::string("is"), std::string("a"), std::string("teapot") }; arrayÚta; } template<class T> class CArrayMember : public T { public: CArrayMember() : T() { } CArrayMember(const CArrayMember &o) : T(o) { } explicit CArrayMember(const T &o) : T(o) { } operator boost::shared_ptr<CArrayMember>() const { return boost::shared_ptr<CArrayMember>(new CArrayMember(*this)); } }; typedef boost::python::indexing::iterator_pair<CArrayMember<std::string> *> MyListCArray; MyListCArray MyList_getArray(MyList &l) { CArrayMember<std::string> *data=static_cast<CArrayMember<std::string> *>(l.getData()); return boost::python::indexing::iterator_pair<CArrayMember<std::string> *> (data, data+100000); // Issue if l is near the 4Gb mark } BOOST_PYTHON_MODULE(TestCArrays) { boost::python::implicitly_convertible<std::string, CArrayMember<std::string> >(); boost::python::class_< MyListCArray, boost::noncopyable>("MyListCArray", boost::python::init<CArrayMember<std::string> *, CArrayMember<std::string> *>()) .def(boost::python::indexing::container_suite< MyListCArray >()); boost::python::class_< MyList, boost::noncopyable >("MyList") .def("getData", &MyList_getArray) ; } -----BEGIN PGP SIGNATURE----- Version: idw's PGP-Frontend 4.9.6.1 / 9-2003 + PGP 8.0.2 iQA/AwUBP4d9/8EcvDLFGKbPEQLYxwCfSIKfJ6mtqNtS76pbNYxTF4OvZZUAoL+3 4O1w8HK0sgRIaFPbxZ5WXbfV =d8TG -----END PGP SIGNATURE-----

5 22

vector<foo*> -> list, preserving identity
by Jacek Generowicz Dec. 3, 2003

Dec. 3, 2003

Imagine I have wrapped (using Boost.Python) 1. a C++ class 2. a function (or method) which returns vector of pointers to said class. I would like to receive the vector as a Python list of instances of the class, but would like the identity of the objects to preserved. IOW, I want the original C++ object at the end of the pointer to be referenced by the Python object which holds it, rather than a new C++ object being instantiated. Here's a minimalized sample of source to demonstrate the situation: #include <Python.h> #include <boost/python.hpp> #include <iostream> #include <vector> using namespace boost::python; struct foo { foo () { std::cout << "Creating foo at " << this << std::endl; } void pointer() { std::cout << this << std::endl; } }; std::vector<const foo*> makefoos(int n) { std::vector<const foo*> fv; for (int i=0; i<n; ++i) { fv.push_back(new foo); } return fv; } BOOST_PYTHON_MODULE( nocopy ) { class_<foo >("foo", no_init) .def("pointer", &foo::pointer); def ("makefoos", makefoos); } How should I write a converter for the std::vector<foo*>, in order to preserve the identity of the foos ? (In the library I am wrapping, the return type of makefoos is actually const std::vector<const foo*>&) Thanks,

2 6

Problem using wrapped void* in Python
by Kor de Jong Dec. 2, 2003

Dec. 2, 2003

Hi all, I am trying to wrap a C struct with Boost.Python which among other members has an opaque pointer to some data, for example: // A class in C. typedef struct AClass { ENUM1 v1; void *data; } AClass; // Boost.Python code to wrap AClass. BOOST_PYTHON_MODULE(amodule) { enum_<ENUM1>("ENUM1") .value("first", first) .value("second", second) ; class_<AClass>("AClass") .def_readwrite("v1", &A::v1) .def_readwrite("data", &A::data) ; } // Python code which uses AClass. import amodule var = amodule.AClass() print var.v1 print var.data This results in the following error message when run: print var.data TypeError: No to_python (by-value) converter found for C++ type: Pv I don't want to use the value pointed to by the void pointer in Python (which can't be done anyway I suppose), I just want to copy it around and pass it to wrapped C functions again. So, what I am looking for is a way to tell Boost.Python how to convert from void* to Python and back. I have tried various things, like the opaque_pointer_converter and the to_python_converter, but I end up with code which I don't understand anymore and/or which doesn't compile. I would be very grateful if one of you could provide me with a bit of code to get me going again. Thanks in advance! Kor de Jong

4 4

Boost.Python Deployment Dependencies
by Paul Grenyer Dec. 1, 2003

Dec. 1, 2003

Hi Im in the process of trying to deploy an application that uses boost.python. I started off by just including the python23.dll (as well as the boost.python dll), but when our python code is executed via boost.python, we get an error suggesting that site.py cannot be found. I then tried installing the python interpreter and libraries as well as our new application, this worked. I then renamed the python23 directory, expecting our application to now fail. It didnt. I am now somewhat confused about what boost.python actually depends on???? I dont want to have to install python on every machine where we want to install our application, I want to be able to include the necessary boost.python dependencies in our install script. Any ideas? Regards Paul Please note the change of email address! Paul Grenyer Email: paul(a)paulgrenyer.co.uk Web: www.paulgrenyer.co.uk

4 3

Dereferenceable concept proposal
by Pierre Barbier de Reuille Nov. 29, 2003

Nov. 29, 2003

In the project I'm working on, we are using intrusive smart pointers. When trying to export classes used with such smart pointers, I had a problem with the dereferenceable concept. This concept require the existence of a 'get' method, but the smart pointer we use does not have this method (ie. the method exists but with another name). We cannot rename the method for it will break to many code, and not only code from us. So, would it be possible to replace this requirement by something like having an expression : get_pointer_from_smart_pointer()( smart_pointer ) get_pointer_from_smart_pointer being a template with this default definition : template <class T> struct get_pointer_from_smart_pointer { typename pointee<T>::type* operator()(const T& ptr) const { return ptr.get(); } } This way, it should not break the existing code and we should be able to use uour smart pointer by just redefining this class. The main problem is, I'm not really able to evaluate the changes needed in the Boost.Python code. And perhaps this solution has tons of defaults I don't see :-/ Thanks, -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68

2 3