Mailman 3 July 2003 - Cplusplus-sig

Pyste and overloaded virtual functions.
by Prabhu Ramachandran July 4, 2003

July 4, 2003

Hi, Sorry to bother you like this every few hours but I've found another bug with Pyste (previous version) when generating code for overloaded virtual functions. Here is a test program. // ---------- overload.hpp ---------- namespace test { class Base { public: virtual void f(const int i) = 0; }; class A : public Base{ public: void f(const int i) {} void f(const double d, const int i) {} }; } // -------------------- When compiling the file that Pyste generates for this, it produces this error message: overload.cpp: In function `void init_module_overload()': overload.cpp:59: no matching function for call to `boost::python::class_<test::A,{anonymous}::test_A_Wrapper,boost::python::detail::not_specified,boost::python::detail::not_specified>::def (const char[2], {unknown type}, void ({anonymous}::test_A_Wrapper::*)(int))' The generated code segment for the function looks like this: .def("f", &test::A::f, &test_A_Wrapper::default_f) .def("f", (void (test::A::*)(const double, const int) )&test::A::f) The fix is to replace it like so: .def("f", (void (test::A::*)(const int) ) &test::A::f, &test_A_Wrapper::default_f) .def("f", (void (test::A::*)(const double, const int) )&test::A::f) Only the first line is changed. I've also attached a patch to ClassExporter.py that fixes this for me. Oh! I just spent an hour and a half debugging this but it looks like this was fixed in the latest version that has the _name bug. FWIW, I've attached the patch anyway but this patch is for the ClassExporter.py version 1.29. cheers, prabhu

2 1

Refactoring, Compilation Speed, Pyste, Lua/Ruby/JavaScript...
by David Abrahams July 3, 2003

July 3, 2003

A number of you (who have my sympathy!) have begun to dig in to Boost.Python's implementation to some degree, usually so you can accomplish something that isn't exposed in the documented interface. I'm sure most of you have noticed that it's not always easy to navigate the internal structure of the library. I'd like to address some of that and at the same time give us the tools to solve some other problems, which I'll discuss at the end. I propose to divide the library's implementation into several namespace layers with corresponding subdirectories of boost/python. These are just rough divisions and I would welcome suggestions for finer-grained layering, or better names, or... These layers are generally ordered from dependencies to dependents. core (for lack of a better name) - This is a Python-independent layer which contains the framework of the type-converter registry, inheritance.hpp which manages base<->derived class conversions, the exception translator framework, boost/python/type_id.hpp, and possibly a few components from the current boost/python/detail. converter - This stuff which handles Python-specific conversion mechanics is mostly already segregated in boost/python/converter, but it could be better organized. Almost everything else in the library is built upon these capabilities function - Wrapping of (member) (function) pointers into Python callable objects. Maybe this should be called "callable". callback - Invocation of Python callable objects from C++, e.g. call_method<...>, call<...> api - various namespace-scope functions such as del(), getattr(), etc. objects - object, str, dict, tuple, list, long_ ... classes - specific support for class wrapping, including instance_holders, support for smart pointers, etc. I see great potential in this reorganization. One thing I'd like to see happen in the near term is that Pyste might be altered to use some lower-level components of Boost.Python directly to improve compile times. For example, instead of relying on Boost.Python to generate wrappers for functions and member functions, Pyste might instead generate function wrappers directly using Boost.Python's type converters. I have no doubt that Python executes faster than the template engine in most C++ implementations! A longer-term goal is to move enough of the code into the core that we could easily re-use it to support other interpreted languages besides Python. Comments? -- Dave Abrahams Boost Consulting www.boost-consulting.com

7 35

Linking Problem, Boost and MSVC
by John Janecek July 3, 2003

July 3, 2003

This is not very scientific, but when it comes to linking with MSVC I have discovered that you get unresolved linking errors unless all the libraries are not linked with the same "code generation". Project, Settings, C++, Code Generation. and then use run-time library. I set it to use Multithreaded-DLL. sometimes warnings still occur but it seems to work. I have been unable to get boost to compile using JAM files so therefore i use the VC IDE like show in the tutorial. Also if anyone is intrested i wrapped jrtp library using boost. http://pyjrtplib.sourceforge.net/ John

2 2

Pyste and virtual operators.
by Prabhu Ramachandran July 3, 2003

July 3, 2003

Hi, My experience with Boost.Python and Pyste have so far been superb. Thanks for the wonderful library and tool! I think I've just found a bug with Pyste regarding handling virtual operators. Virtual functions seem to be OK but operators cause trouble. Consider the following minimal test code: // ------- file.hpp ------------- namespace test { class Op { public: virtual ~Op() {} virtual Op& operator ++ () = 0; }; } // -------------------- I now wrap this using something like so in a Pyste file. op = AllFromHeader('file.hpp') When generating file.cpp everything is fine but when compiling the file errors are generated since the wrapper code does not generate wrappers for the operator and this cannot be instantiated. In the above case there is no wrapper code generated at all. The problem also persists with concrete virtual member operators -- since the wrappers are not generated. The code compiles but there would be problems since one would not be able to overload it in a derived class in Python. I guess this is a bug? Thanks! cheers, prabhu

2 1

question about using a python object from C++
by Shi Sherebrin July 3, 2003

July 3, 2003

hello, I've spent a lot of time reading the Boost web pages, and I'm still mystified. I have a class that I built in Python. I want to use this class in C++. From reading about Boost it seems to allow bidirectional operation, but I can't find a simple (or any) example of using C++ to access a Python object. Could someone please point me in the right direction? Further digging has led me to the "embedding Python" pages of the main python docs, but that seems quite complicated for C++, and I'd imagine simplifying that is one of the things Boost.Python does. So is there a simple example somewhere of how to do this: In Python I have defined the class "myclass", and it has methods "Init", "Run" & "Shutdown" Ideally, in C++ I want to be able to do something like: <include "myclass.h"> ... myclass obj; obj.Init(initdata); obj.Run(params); obj.Shutdown(); thanks in advance for any help on this, Shi.

3 2

Pyste overload problem
by Jim Wilson July 3, 2003

July 3, 2003

Pystitos, Earlier, I posted a Pyste problem on g.c.l.b.user, to a deafening silence: http://article.gmane.org/gmane.comp.lib.boost.user/3793 so I presume I posted to the wrong list. I notice most Pyste discussion is here, and that similar complaints suggest "Get the CVS" as a panacea. Sure enough, after an hour of CVS and another hour of building, the problem is gone! Alas, another similar one takes its place. foo.h: void bar(char**); void bar(); foo.pyste: Function("bar", "foo.h") Pyste issues no "needs-a-policy" complaint. Instead, it apparently generates code which calls bar(char*), a function which does not exist. Any advice? Jim Wilson Gainesville, FL

2 2

Linking problem
by Philippe Fremy July 2, 2003

July 2, 2003

Hi, I get a beyound-my-level-of-comprehension linking problem with boost and msvc. The problematic code is : typedef const char * (*data2str)( const unsigned char * data, int len ); template<data2str f> char const * data2strWrapperWithList( boost::python::list dataList ) { Apdu apdu = list2apdu( dataList ); return (const char *) ((*f)( apdu.bytes(), apdu.len() )); } [...] // hex2str functions def( "hex2str", data2strWrapperWithList<hex2str> ); def( "block2str", &(data2strWrapperWithList<block2str>) ); [...] Visual reports me a "Unresolved external symbol: char const * __cdecl data2strWrapperWithList( class boost::python::list)" (?...) It links fine if I comment the .def related to these data2str converters. It links fine under linux. Does anybody have any hint ? regards, Philippe ps: please include my in any replay as I am not subscribed. -- Talk less, code more!

2 1

passing a dynamic PyObject * from C++ to Python
by F. Oliver Gathmann July 1, 2003

July 1, 2003

I have a function that reads a file and returns (depending on the content of the file) either a Foo or a Bar wrapped in a PyObject* (both Foo and Bar objects are expensive to copy and have to be passed via a smart pointer). With Boost.Python v1 I was able to do PyObject * readFile(char const * fileName) { PyObject * obj; FileInfo info(fileName); if (info.isFoo()) { std::auto_ptr<Foo> foo(new Foo(info.data())); obj = to_python(foo); } else { std::auto_ptr<Bar> bar(new Bar(info.data())); obj = to_python(bar); } return ref(obj); } and wrap this like so: BOOST_PYTHON_MODULE_INIT(vigracore) { module_builder this_module("reader"); this_module.def(&readFile, "readFile"); } With Boost.Python v2, I have not been able to find an equivalent solution; I tried various approaches gathered from the Boost.Python FAQ and documentation, e.g. template <class T> T identity(T x) { return x; } template <class T> object get_pointer_reference(T x) { object f = make_function(&identity<T>, return_value_policy<manage_new_object>() ); return f(x); } object readFile(char const * fileName) { FileInfo info(fileName); if (info.isFoo()) { Foo * fooPtr = new Foo(info.data()); return get_pointer_reference(fooPtr); } else { Bar * barPtr = new Bar(info.data()); return get_pointer_reference(barPtr); } } BOOST_PYTHON_MODULE(reader) { def("readFile", &readFile); } which compiles fine but crashes at runtime (using gcc 3.2.2 on Linux with a recent CVS version of Boost). Any hints that might help me solving this mystery would be much appreciated! Oliver -------------------------------------------------------------------- F. Oliver Gathmann, Ph.D. Director IT Unit Cenix BioScience GmbH Pfotenhauer Strasse 108 phone: +49 (351) 210-2735 D-01307 Dresden, Germany fax: +49 (351) 210-1309 fingerprint: 8E0E 9A64 A07E 0D1A D302 34C2 421A AE9F 4E13 A009 public key: http://www.cenix-bioscience.com/public_keys/gathmann.gpg --------------------------------------------------------------------

6 9