Mailman 3 November 2002 - Cplusplus-sig

Re: [C++-sig] VC7 + auto_ptr + transfer of owership
by Nicolas Lelong March 17, 2003

March 17, 2003

>auto_ptr support is only really complete in the current CVS >version. There are some problems with it in 1.29.0. Huhf, I'm afraid that I checkouted the yesterday's version, and that's the one that causes the problem ! Any idea ? Thanks, Nicolas _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 6

MSVC project file
by Brett Calcott Jan. 7, 2003

Jan. 7, 2003

Hi all, For those interested here is a MS project file that builds boost_python. Create a directory under boost/libs/python/build I called mine ./msvc-project. Drop the file into the directory and then load it in DevStudio and build. It will create a ./bin underneath it with boost_python.dll and boost_python_d.dll. David, (if you are listening) given the work in Boost.Build I'm not sure if you are interested in this at all - though I would hazard a guess that there will be more requests. In any case - adding some extra warning switches to the detail/config.hpp makes the build a little easier to watch both for bjam and DevStudio. --- config_old.hpp Sat Nov 09 19:47:06 2002 +++ config.hpp Sat Nov 09 16:19:26 2002 @@ -32,7 +32,11 @@ # define BOOST_MSVC6_OR_EARLIER 1 # endif -# pragma warning (disable : 4786) +# pragma warning (disable : 4786) // disable truncated debug symbols +# pragma warning (disable : 4251) // disable exported dll function +# pragma warning (disable : 4800) //'int' : forcing value to bool 'true' or 'false' +# pragma warning (disable : 4275) // non dll-interface class + # elif defined(__ICL) && __ICL < 600 // Intel C++ 5

11 45

operator problem
by gaoyakun Dec. 10, 2002

Dec. 10, 2002

I have exported my point3 class to python, with many overloaded operators. it works fine for me except the *= operator. it always tell me "can't multiply sequence with non int type". but if i use p1.__imul__(p2) instead of p1 *= p2, it successfully executed my code. what's wrong with me? this is some code of my point3 class class point3 { .. ... point3 & operator *= (const point3 &p) { v[0] *= p.v[0]; v[1] *= p.v[1]; v[2] *= p.v[2]; return *this; } point3 & operator *= (float t) { v[0] *= t; v[1] *= t; v[2] *= t; return *this; } .... }; in to_python.cpp: class_<point3>("point3") ... ... .def(self *= self) .def(self * self) .def(self *= other<float>()) .def(self * other<float>()) ... ... what's the problem? ______________________________________ =================================================================== Ãâ·ÑÊÔÓÃÐÂÀË15MÊÕ·ÑÓÊÏä žÏœôÐÐ¶¯£¡ (http://vip.sina.com/sol_mail/promotion/pro_men.html) ÐÂÀË¶þÊÖÊÐ³¡£ºÒ»ÔªÍ¶Èë£¬Ê®·ÖŸªÏ²£¬°Ù·ÖÂúÒâ (http://classad.sina.com.cn/2shou/) ÊýÍòÕÅÊÖ»úÍŒÆ¬ÊýÍòÊ×¶ÌÐÅÁåÉùÈÎÄãÌôÑ¡£¬Ã¿Ìì¶ŒÓÐžüÐÂ (http://sms.sina.com.cn/cgi-bin/sms/smspic.cgi)

5 9

container_conversions.h with VC7
by Achim Domma Dec. 8, 2002

Dec. 8, 2002

Hi, using Ralfs container_conversion.h with VC7 I get an internal compiler error. The problem seems to be the loop in the lines 165 to 176: for(;;i++) { handle<> py_elem_hdl(allow_null(PyIter_Next(obj_iter.get()))); if (PyErr_Occurred()) { PyErr_Clear(); return 0; } if (!py_elem_hdl.get()) break; // end of iteration object py_elem_obj(py_elem_hdl); extract<container_element_type> elem_proxy(py_elem_obj); if (!elem_proxy.check()) return 0; if (is_range) break; // in a range all elements are of the same type } If I comment out the body of the loop, everyting works fine. An older version of bpl_utils had an workaround for VC6 in this function, but I can't get it to work. Does anybody know a workaround? regards, Achim

7 31

Static, again...
by Hugo van der Merwe Dec. 5, 2002

Dec. 5, 2002

I had a look at the mailing list archives about this topic, I'm still not clear on how exactly it works: > #include <boost/python/module.hpp> > #include <boost/python/class.hpp> > > struct Num { > Num() {} > ~Num() {} > static int getDims() {return 3;} > int dims() {return 5;} > }; > > BOOST_PYTHON_MODULE_INIT(numTest) > { > using namespace boost::python; > module numTestMod("numTest"); > numTestMod > .add > ( class_<Num>("Num") > .def_init() > .def("getDims",&Num::getDims) > .def("dims", &Num::dims) > ) > ; > } > We don't have a way to make true static methods yet. > getDims will work fine if you access it through the class like this: > > Nums.getDims() I am trying to wrap a "Settings" class which does not have a public constructor, it expects you to call "GetInstance" to get a pointer to the always-existing instance (making the settings "global"). The above would make me think that this will work: class_<Settings, boost::noncopyable>("Settings", no_init) .def("GetInstance", &Settings::GetInstance, return_value_policy<reference_existing_object>()); I cannot call Settings.GetInstance(), it gives me: TypeError: unbound method Boost.Python.function object must be called with Settings instance as first argument (got nothing instead) I also read about an approach that looks something like this: object settings_class = class_<Settings, boost::noncopyable>("Settings", no_init); settings_class.attr("Settings") = &Settings::GetInstance; But I don't know how that is supposed to work... If I wanted to expose GetInstance as Settings() instead (once I get it working), is it as simple as just calling it "__init__" instead? (Should I then have no_init in the class_<> invocation or not? I noticed the tutorial talks about no_init, but then mentions as soon as you wish to derive classes from it, you do not want no_init. So when is no_init useful? Only when you cannot construct a class and don't want to derive from it, i.e. when you're using "factories"?) I am really astonished with what can be achieved with C++ - Boost.Python is really amazing! Thanks a lot, Hugo van der Merwe

5 13

Re: call_method
by David Abrahams Dec. 4, 2002

Dec. 4, 2002

"Peter Dimov" <pdimov(a)mmltd.net> writes: >> I'd like to explore a few refinements with you. For example, it may >> be possible to get real shared_ptr interoperability by deriving >> py_counted_base from counted_base. Maybe we should ask Peter to >> weigh in on this. Peter, Brett's code is attached to this page: >> http://aspn.activestate.com/ASPN/Mail/Message/1430235 > > I don't really understand what the code is about ;-) Here's the quick skinny: - Boost.Python allows you to specify how Python objects will hold the C++ objects they wrap. You can specify that they be held by shared_ptr<T> (or any other smart pointer), in which case the library will generate converters to/from Python for shared_ptr<T>. The to_python converters will simply build a new Python object around the shared_ptr<>. - If you have virtual functions you want to ``override in Python'', you actually have to hold the T object with a derived class U which overrides the virtual functions to dispatch back to Python. In this case, class U naturally has to have access to the Python object (that's the pyobj_ member you see in Brett's code). - You can further specify that your C++ object is held by shared_ptr<U>, which is what Brett is doing. That allows you to hold a U object for dispatching, yet still pass shared_ptrs around in your C++ code. There are several problems with the above arrangement, but the most important one is that if you keep the shared_ptr<U> alive longer than its corresponding Python object, calls to the Python-overridable virtual functions will crash, because they'll try to call through an invalid pointer. That's what Brett is trying to address with his crazy pointer. > but I'm leaning towards moving counted_base back to boost::detail > and removing the intrusive counting "feature" of shared_ptr. > > The interoperability/shared_from_this problems have alternate solutions as > described in the techniques "document". Hmm. I guess that rules out that option. > I'm not sure whether this helps or not, but it's also possible to have a > shared_ptr to PyObject, by using Py_DECREF as the deleter (also described in > the attached file). Now /that's/ starting to sound intriguing. I wonder if it's possible to derive our U class from boost::python::objects::instance<>, and automatically generate shared_ptr<> converters for it. Maybe the whole idea of holding a shared_ptr<U> is bogus from the get-go. -- David Abrahams dave(a)boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution

2 14

Contributing an embedding example (after a bugfix ;)
by Dirk Gerrits Dec. 3, 2002

Dec. 3, 2002

After receiving a lot of help in another thread (thanks!) I was able to get my little Boost.Python program using embedding to compile and run. It works great! But upon deinitialization with Py_Finalize(), I get an error: Fatal Python error: PyThreadState_Get: no current thread I don't really know what is causing this, so I am asking for your help again. :) After having fixed this though, I'd be willing to contribute this as an example for Boost.Python, if there is interest. I thought it was a pretty neat technique myself. ;) Before that, I'd need to Boostify the code a bit though, and I am wondering if all of it is necessary. For example, BaseWrap seems a bit superfluous since I'm only using Base's polymorphism from the C++ side. Any comments on this? Regards, Dirk Gerrits #include <iostream> #include <boost/python.hpp> #include <boost/python/extract.hpp> #include <boost/python/converter/registry.hpp> namespace python = boost::python; // The abstract base class class Base { public: virtual ~Base() {}; virtual void f() = 0; }; // The C++ derived class class CppDerived : public Base { public: virtual ~CppDerived() {} void f() { std::cout << "CppDerived::f()\n"; } }; // The Python derived class class PythonDerived : public Base { public: PythonDerived() : m_instance(ms_class_object()) {} virtual ~PythonDerived() {} void f() { m_instance.attr("f")(); } static void SetClassObject(python::object const& class_object) { ms_class_object = class_object; } private: static python::object ms_class_object; python::object m_instance; }; python::object PythonDerived::ms_class_object; namespace { // The Boost.Python wrapper class for Base struct BaseWrap : public Base { BaseWrap(PyObject* self_) : self(self_) {} void f() { return python::call_method<void>(self, "f"); } PyObject* self; }; } // Pack the Boost.Python wrapper for Base in a module BOOST_PYTHON_MODULE(pythontest) { python::class_<Base, BaseWrap, boost::noncopyable>("Base", python::no_init) ; } int main() { //- INITIALIZATION ------------------------------------------------------// // Register the module with the interpreter PyImport_AppendInittab("pythontest", initpythontest); // Initialize the interpreter Py_Initialize(); // Load the module PyObject* mainmod = PyImport_AddModule("__main__"); PyObject* ns = PyModule_GetDict(mainmod); Py_INCREF(ns); // Define the derived class in Python (you'll want to put this in a .py file) PyObject* x = PyRun_String( "from pythontest import *\n" "class PythonDerived(Base):\n" " def __init__(self):\n" " pass\n" " def f(self):\n" " print \"PythonDerived::f()\"\n", Py_file_input, ns, ns); Py_XDECREF(x); // Extract the Python object representing the just defined derived class PyObject* class_ptr = PyRun_String("PythonDerived\n", Py_eval_input, ns, ns); python::handle<PyObject> handle(class_ptr); python::object class_object(handle); PythonDerived::SetClassObject(class_object); //- MAIN PROGRAM --------------------------------------------------------// // Create and use an instance of the C++ derived class boost::shared_ptr<Base> cpp(new CppDerived); cpp->f(); // Create and use an instance of the Python derived class boost::shared_ptr<Base> py(new PythonDerived); py->f(); std::cout << "\nPress <enter> to quit..."; std::cin.get(); //- CLEAN UP ------------------------------------------------------------// // Release the Python interpreter Py_Finalize(); }

2 7

Conversion from python objects to c++ objects for argument passing
by Nicodemus Nov. 29, 2002

Nov. 29, 2002

Hail! First, let me congratulate everyone involved in Boost.Python. The more you use it, the more you see how great the library is! I'm having a little problem though. I want that the following function: void PrintVec( const vector<int> &v ) { vector<int>::const_iterator it = v.begin(); stringstream ss; ss << "C++: ["; while ( it != v.end() ){ if ( it != v.begin() ){ ss << ", "; } ss << *it; } ss << "]"; cout << ss.str() << endl; } Be called like this from python: >>> PrintVec([1,2,3]) C++: [1, 2, 3] To accomplish that, I've been using this lvalue converter: struct pylist_to_vector { static vector<int>& execute(PyObject& o) { static vector<int> v; v.clear(); cout << "execute" << endl; if ( PyList_Check(&o) ){ int size = PyList_Size(&o); cout << "size is " << size << endl; v.reserve( size ); for( int i = 0; i < size; ++i ){ PyObject* item = PyList_GetItem(&o, i); if ( PyInt_Check(item) ){ int num = PyInt_AsLong(item); v.push_back( num ); } else { cout << "Not a num at: " << i << endl; } } } cout << "returning..." << endl; return v; } }; and in the module definition: BOOST_PYTHON_MODULE(test) { lvalue_from_pytype<pylist_to_vector, &PyList_Type>(); def( "PrintVec", &PrintVec ); } Everything links and compiles without a problem. But, when I execute: >>> PrintVec([1,2,3]) execute size is 3 returning... in python, it enters in an infinite loop and never stops. Debugging, I found out that it enters into my function, exits it, goes through boost.python, until it enters this code: /* file returning.hpp, line 114 template<class P BOOST_PP_ENUM_TRAILING_PARAMS_Z(1, N, class A)> static PyObject* call( R (*pf)(BOOST_PP_ENUM_PARAMS_Z(1, N, A)) , PyObject* args_ , PyObject*, P const* policies) { // check that each of the arguments is convertible BOOST_PP_REPEAT_1ST(N, BOOST_PYTHON_CHECK_CONVERSION, nil) if (!policies->precall(args_)) return 0; (*pf)(BOOST_PP_REPEAT_1ST(N, BOOST_PYTHON_CALL_ARGS, nil)); return policies->postcall(args_, detail::none()); } In the "return 0;" line, the processor hits 100% and the application blocks. So, what am I doing wrong? Is this the right way to accomplish what I want? I'm using Intel C++ 6 with STLport on windows. Thanks for any hints and comments, Bruno da Silva de Oliveira.

2 4

Support for virtual functions with default implementations
by David Abrahams Nov. 27, 2002

Nov. 27, 2002

Some of you have been struggling with a supposed inability of Boost.Python v2 to correctly expose virtual functions with default implementations. You can read all about the nitty-gritty details at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/… The bottom line, when exposing a class B with its "callback" class Bcb... struct B { virtual std::string f() { return "B"; } }; struct BWrap : B { BWrap(PyObject* self) : m_self(self) {} virtual std::string f() { return call_method<std::string>(m_self, "f"); } std::string f_default() { return B::f(); } PyObject* m_self; }; ...turns out to be that sometimes, from Python, B.f() must invoke B::f virtually (e.g. when the Python object actually holds a [smart] pointer to some C++ class derived from B), and sometimes it must invoke BWrap::f_default, which invokes the actual B::f defined in B. Well, after several weeks of working on a complicated solution to this problem, I had an Aha! moment, and realized that we already had the capability!** The key is simply to expose your class like this: class_<B, BWrap // or, e.g., shared_ptr<BWrap> >("B") .def("f", &B::f) // dispatch function .def("f", &BWrap::f_default) // default implementation ; That's it! Because later def() overloads get precedence, your default implementation will be used if the Python object actually contains a BWrap object. Otherwise, it will call B::f virtually. Issues: 1. f_default MUST be a member function of BWrap, or take a BWrap& first argument 2. You MUST def() f_default second. Failure to get either of these right will result in crashes or other runtime failures. I have just checked in changes which allow you to supply your default implementation in the .def() invocation: .def("f", &B::f, &BWrap::f_default) This version will catch those potential errors at compile-time. However, the other version should work fine with the Boost 1.29.0 release. -Dave **Don't worry, the weeks weren't a complete waste; the code got a lot cleaner as I refactored things. -- David Abrahams dave(a)boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution

1 0

Boost.Python Function overload resolution order
by David Abrahams Nov. 27, 2002

Nov. 27, 2002

I just discovered something surprising in Boost.Python's function overload resolution: overloads are tried in the _reverse_ order in which they are def'ed. I actually thought it worked the opposite way! Changing this could break user code which relies on the current order: void f(float); void g(int); ... def("f", f); def("f", g); If we change the rules so that the first def() is tried first, g will neve be called. However, I consider the current rule to be counter-intuitive and surprising. Quite a dilemma. Opinions? -- David Abrahams dave(a)boost-consulting.com * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution

2 3