Mailman 3 January 2002 - Cplusplus-sig

trouble with virtual methods
by Hugo van der Merwe Feb. 3, 2002

Feb. 3, 2002

I cannot track down what I'm doing wrong. Here follows code extracts from what I'm struggling with. If anyone can point me in the direction I should investigate, that would be great. Terrain.h contains: ------------ class TextureFactory { public: virtual GLuint GetTexture(int index,float originX,float originY,float width,float height) = 0; virtual void UnloadTexture(int index,float originX,float originY) = 0; }; ------------ My wrapper code contains: ------------ class TextureFactory_callback : public TextureFactory { public: TextureFactory_callback(PyObject* self) : /*TextureFactory(),*/ m_self(self) { cout << "here I am" << endl; } ~TextureFactory_callback(){ cout << "ack, I'm dead!" << endl; } GLuint GetTexture(int index, float originX, float originY, float width, float height) { return python::callback<GLuint> ::call_method(m_self, "GetTexture", index, originX, originY, width, height); } void UnloadTexture(int index, float originX, float originY) { return python::callback<void>::call_method(m_self, "UnloadTexture", index, originX, originY); } private: PyObject* m_self; }; void func(TextureFactory* t){ t->GetTexture(0,0,0,0,0); } BOOST_PYTHON_MODULE_INIT(demeter) { python::module_builder this_module("demeter"); python::class_builder<TextureFactory,TextureFactory_callback> TextureFactory_class(this_module, "TextureFactory"); this_module.def(func, "func"); <snip> } ------------ Now in Python I do: >>> import demeter >>> class boo(demeter.TextureFactory): ... def GetTexture(a, b, c, d, e): print "gotcha:",a,b,c,d,e ... >>> tf = boo(); here I am >>> demeter.func(tf) Aborted And so it bombs out. I have looked at examples and documentation, but have not found the answer yet. (Note, libs/python/doc/overriding.html has a "struct baz_callback {" which I guess should be "struct baz_callback : baz {" ? I have 1.26.0) Thanks, Hugo

3 9

Boost.Python queries
by Hugo van der Merwe Jan. 29, 2002

Jan. 29, 2002

I have the following error: demeter.cpp:134: no matching function for call to `boost::python::tuple::tuple (float &, float &, float &, int &, int &, float &, float &, bool &)' I typecast the last bool to an int when passing to tuple, that solved it. Am I pushing internal but arbitrary limits of Boost again? Exceptions: I checked the examples - they show nicely how to raise an exception in your wrapper code. Is there a way to have exceptions that are raised in the wrapped code automatically converted though? (Otherwise one would have to write an exception-converting thin wrapper for each method.) Is there not some way one could e.g. "install" a "default exception converting wrapper" automatically? (Some way it can be included in V2?) Thanks, Hugo van der Merwe

2 3

Current Version
by Achim Domma Jan. 28, 2002

Jan. 28, 2002

Hi, how can I get the current beta version of boost.python ? I hope to write an article about it soon, so I would like to write my code based on the newest version. greetings Achim

2 2

Boost.Python and lifetime of instances of C++ classes
by Hugo van der Merwe Jan. 24, 2002

Jan. 24, 2002

I've attached the source for a python extension (test.cpp), and a test.py script, that uses it. Here is the output of the test.py script: ========== k = test.testclass(): test Constructor called. k.printit(): HELLO! l = test.foo() l.add(k) l.printit(): HELLO! k = 0 test Destructor called. l.printit(): HELLO! ========== How does this work? Since "test Destructor called." appears, I'd think k has been destroyed/deallocated. Then l.printit() calls k.printit(), from C++. Something's odd, possibly even dangerous. Can someone explain this? Sorry if this does not compile under Windows - what's required, just the "boilerplate" thingy added at the end of test.cpp? Thanks, Hugo

3 6

building boost ...
by Hugo van der Merwe Jan. 24, 2002

Jan. 24, 2002

Can anyone point me to somewhere I can find out how to easily build boost against Python 2.1 instead of 1.5, and to make dynamic libraries for dynamic linking? Thanks, Hugo

2 3

generic object wrappers
by Arnaldur Gylfason Jan. 24, 2002

Jan. 24, 2002

<<< > convenience. In operators you define addable, subtractable etc. same > way we aim for the capabilities. So maybe it makes sense to define > sets, like additive, arithmetic, ring etc. just as in operators. Maybe. I find all of those combinations in operators.hpp a bit daunting, but I'm sure that some people find them indispensable. >>> I believe many of the abstractions in operators are clear to those used to mathematical language, esp. abstract algebra. For those object<ring> would be clear and might be considered superior to object<addable,subtractable,multipliable>. Those who find it unclear could happily ignore these combinations. This is not important though. <<< I would find it useful; there's quite a bit of casting involved in some of the newest code. I always intended that Boost.Python would be good for users who want to create a new extensioni type directly (rather than wrapping some C++ type). In other words, Boost.Python should be a framework, with the high-level parts easiest to use but with lower level facilities which still help you write effective Python components in C++. Your work falls in the middle area. > The Python C API always work with PyObject*, even in > functions working with concrete types like list. The PyObject*is > converted to PyListObject* within the function. If we would have > API functions for PyObject*, PyListObject* (and MyListSubtype*) > etc. I could see direct benefit from the design > above. reference<T>::get() would pass in all cases. Don't forget, once you downcast to PyListObject*, you can build a reference<PyListObject*>, use that, and all casting disappears. ... Your reasoning is sound, but you may have overlooked cases like boost/python/object/class_wrapper.hpp and libs/python/src/object/class.cpp. Maybe those cases aren't common enough to warrant such a feature. >>> Yeah I meant to add that maybe you needed it in other parts of boost.python. Sadly, I must admit I have not taken a look at other parts and can't comment on them at this stage. All in all I believe this design is good and 1 case where it will benefit you (or me) is enough to warrant it. Regarding typecasts, yes they're ugly. Inside a concrete object wrapper like list it should be safe though. Using a reinterpret_cast makes the typecasts obvious in code. After downcasting to a PyListObject* I could build a reference<PyListObject*> and benefit from automatic conversions after that yes, but the usage I had in mind was just touch and go, i.e. there wasn't really any need of keeping a PyListObject*, I just needed the typecast to access an attribute for the PyListObject instance (obitem). I think most uses of these typecasts/conversions in the object interface part are similar to that. Don't get me wrong though. It is quite possible I will find out that this design comes in handy later. Cheers Arnaldur

3 3

thin wrapper example in docs...
by Hugo van der Merwe Jan. 24, 2002

Jan. 24, 2002

The following example appears in the Pointers section of the Boost.Python docs: const Foo* f(); // original function const Foo& f_wrapper() { return *f(); } ... my_module.def(f_wrapper, "f"); Am I correct in thinking: - Here f() returns a new pointer to an instance of Foo. - The Python f() call calls f_wrapper, which returns a reference to this intance of Foo, which is then copied to a new instance created and "tracked" by python, using Foo's copy constructor. - If f() creates a new instance of Foo, nothing disposes this instance, is there then not a memory leak? Technically, the pointer returned by f() may point to an instance that some other part of the code has rw access to, so while the function calling f() can not change the object due to it being const, something else may still change it. Thus behaviour of the python object may be not as expected, since it has been copied, and a change in the original will not be reflected in the "python copy". This brings forwards another thought: if the pointer points to an instance that is used elsewhere, it cannot be disposed after it's been copied? So when, how and where must the Foo* returned by f() be disposed? I do not yet have a firm grasp of all things C++ related. I may be mistaken in my understanding? Thanks, Hugo van der Merwe

2 2

new to python wrapping...
by Hugo van der Merwe Jan. 22, 2002

Jan. 22, 2002

Hello, I've lately started playing with Python wrapping. Tried both SWIG and Boost.Python, I'm thinking so far that Boost.Python's C++ and Python specific nature will make it more ideally suited to what I want to do (I don't care about bidnings other scripting languages). I've got two questions so far. One is what happens with garbage collection: if I create an instance of an object from a Python script, then add this to e.g. a list in some other C++ class, Python won't know it is still being used, and will try to garbage collect it? The other is a problem I'm having with a constructor. It worked previously, but after the latest changes in the source, I'm getting the following (it's a pretty ugly looking constructor ;) : C++ header: <SNIP> class TERRAIN_API Terrain { public: Terrain(const char* szElevationsFilename,const char* szTextureFilename,const char* szDetailTextureFilename,float vertexSpacing,float elevationScale,int maxNumTriangles,bool bUseBorders = false,float offsetX = 0.0f,float offsetY = 0.0f,int numTexturesX = 0,int numTexturesY = 0); <SNIP> Boost.Python using wrapper: <SNIP> python::class_builder<Terrain> Terrain_class(this_module, "Terrain"); Terrain_class.def(python::constructor<const char*, const char*, const char*, float, float, int, bool, float, float, int, int>()); <SNIP> The error I get when compiling it: demeterwrap.cpp: In function `void initdemeterwrap(...)': demeterwrap.cpp:87: wrong number of template arguments (11, should be 10) /usr/include/boost/python/detail/signatures.hpp:134: provided for `template <class A1 = struct boost::python::detail::void_t, class A2 = struct boost::python::detail::void_t, class A3 = struct boost::python::detail::void_t, class A4 = struct boost::python::detail::void_t, class A5 = struct boost::python::detail::void_t, class A6 = struct boost::python::detail::void_t, class A7 = struct boost::python::detail::void_t, class A8 = struct boost::python::detail::void_t, class A9 = struct boost::python::detail::void_t, class A10 = struct boost::python::detail::void_t> boost::python::constructor<A1,A2,A3,A4,A5,A6,A7,A8,A9,A10>' demeterwrap.cpp:87: confused by earlier errors, bailing out I'm using a really old Boost, as it seems to be the latest one that is packaged for Debian, and I'm lazy atm. I'll compile Boost from source if necessary, but it seems from the Changelogs that Boost.Python hasn't had much updates since Y2K? Maybe Boost libs used by Boost.Python have updated, and that makes a difference? The Debian package version is 1.21.1-1, i.e. some incarnation of 1.21, and I think Boost is currently at 1.26 or something? I hope this isn't something silly I've done that causes this, but I definately count 11 parameters in the C++ constructor, as well as my attempt at a python wrapping of it... Any ideas? Thanks, Hugo van der Merwe

2 3

generic object wrappers
by Arnaldur Gylfason Jan. 22, 2002

Jan. 22, 2002

<<< > I've looked at mpl and am comfortable using it. I feel we should use it > while in development and not worry about rewriting stuff unless mpl will > not be officially in boost when the boost.python rewrite is ready. Agreed. It might be choking one of my most important targets, but I'm not sure yet. I hope not. >>> It's an experiment (an interesting one). It either works or not. If it works the interface to users will be relatively straight forward. The complexity will be hidden from them in the implementation. Even if we have to rewrite things, it won't take too long. (Maybe you were referring to something else?) <<< > We have discussed sets of capabilities like integral, etc. I was > wondering if we should pick a few concepts from boost.operators as > sets of capabilities. Well, I'm beginning to wonder if this is all too complicated to be worthwhile. If not, that would be my fault :(. >>> I don´t think so. Again, complexity should be hidden from the user. Also my comment above shouldn't make things complicated. It´s for convenience. In operators you define addable, subtractable etc. same way we aim for the capabilities. So maybe it makes sense to define sets, like additive, arithmetic, ring etc. just as in operators. <<< Take the easy way out and re-use the MPL primitives like I did. from boost/python/class.hpp in CVS: // A type list for specifying bases template < BOOST_MPL_LIST_DEFAULT_PARAMETERS(typename B, ::boost::mpl::null_argument) > struct bases : ::boost::mpl::type_list< BOOST_MPL_LIST_PARAMETERS(B) >::type {}; // A type list for specifying arguments template < BOOST_MPL_LIST_DEFAULT_PARAMETERS(typename A, ::boost::mpl::null_argument) > struct args : ::boost::mpl::type_list< BOOST_MPL_LIST_PARAMETERS(A) >::type {}; It saved me from having to learn all about the preprocessor library right now ;-) >>> Sounds good! I'll do that. <<< As I was checking my latest work I ran into lots of reference-counting problems, which just reminded me of the importance of religiously using the stuff in reference.hpp. I began to think about a redesign which would also help hide the fact that, e.g. PyTypeObject isn't really derived from PyObject. The design looks like this: 1. A traits class is defined as follows: template <class T> struct base_type_traits { typedef PyObject type; }; This could be specialized for types which are derived from other Python types. For example, it is now possible to make a new extension type derived from dict, list, mapping, or int: template <> struct base_type_traits<MyListSubtype> { typedef PyListObject type; }; 2. A small metaprogram constructs a proxy object which is implicitly convertible to T* for T in the chain of base types: template <class T> struct reference_proxy : reference_proxy<typename base_type_traits<T>::type> { typedef typename base_type_traits<T>::type base_t; reference_proxy(T* p) : reference_proxy<base_t>((base_t*)p) {} operator T*() const { return (T*)m_p; } } template <> struct reference_proxy<PyObject> { public: reference_proxy(PyObject* p) : m_p(p) {} operator PyObject*() const { return (PyObject*)m_p; } PyObject* m_p; } 3. This proxy is the result of reference<T>::get(). The default argument to reference<> is PyObject so we can write python::reference<> most of the time. 4. We can use the traits to manage the implicit convertibility between different reference<> specializations. Well, anyway, it's a thought. Less ambitious than what you're doing and immediately useful. On the other hand, I can do it if you'd prefer ;-) >>> This looks neat! Just to be sure, reference<MyListSubtype>::get() would return a reference_proxy<MyListSubtype> which inherits from reference_proxy<PyListObject> which inherits from reference_proxy<PyObject>. It would thus provide automatic conversions to PyObject*, PyListObject* and MyListSubtype*, just as if they were related through C++ inheritance. I have been thinking about it's use though. In the generic wrappers I only work with PyObject* and don't need anything else. In concrete objects like list, we know the type and can safely typecast to PyListObject* if/when needed (I did that in the iterator support). The Python C API always work with PyObject*, even in functions working with concrete types like list. The PyObject*is converted to PyListObject* within the function. If we would have API functions for PyObject*, PyListObject* (and MyListSubtype*) etc. I could see direct benefit from the design above. reference<T>::get() would pass in all cases. If you want to provide interfaces for different specializations of reference<T> and provide implicit convertibility on that level, the design would help. function f(reference<PyListObject>) could then be called with a reference<PyListObject> and reference<MyListSubtype>. I did not foresee many interfaces that work on the reference level though. E.g. rather than f(reference<PyListObject>) I would have f(list). a MyListSubtype would be used as a generic object (object<indexable,...>) but the automatic conversion to list would call PyList_Check and pass it. Thus the function f can be called on a MyListSubtype. I am probably out in the wild. I'm just trying to imagine usage of the above design. Please tell me what usage you had in mind. Cheers Arnaldur

2 1

generic object wrappers
by Arnaldur Gylfason Jan. 21, 2002

Jan. 21, 2002

Dave, Just letting you know I'm still alive. I started teaching 2 weeks ago (on top of everything else (stupid me!)) and am a little stressed out these days. Still I´ll find time for implementing the generic object wrappers, hopefully soon. Have faith. I've looked at mpl and am comfortable using it. I feel we should use it while in development and not worry about rewriting stuff unless mpl will not be officially in boost when the boost.python rewrite is ready. I've been thinking about the interface for users. Let's say someone need addable, callable and indexable, the interface would be object<addable,callable,indexable> If we would use 1 typelist as a template parameter to object<>, the interface would be: typedef mpl::typelist<addable,callable,indexable> my_capabilities; object<my_capabilities> Somewhat more cumbersome. I feel the former (as we discussed) is better. That means we offer a variable number of template parameters. I've been looking at the boost.preprocessor library and the preprocessor stuff in mpl, and I now understand how mpl uses macros to generate struct declarations that allow a variable number of parameters. I think we should opt for that approach. I have to say though, that understanding this macro logic is much harder than understanding template programming. Still it is a tool worth using to avoid repetition. We have discussed sets of capabilities like integral, etc. I was wondering if we should pick a few concepts from boost.operators as sets of capabilities. Enough said. I aim to begin by writing a core set of capabilities and then writing the object<> wrapper. As you mentioned, it is probably better to write the capabilities that form the generic object interface and provide it before we turn to the mete-programming approach. Let´s see. If I get enthusiastic I´ll probably start experimenting with the meta-programming stuff. Cheers Arnaldur

2 1