[C++-sig] [Boost.Python] Recommended file structure layout?
Hello, I am very interested in using Boost.Python to test my C++ codebase. However, I would like to have some tips on a typical layout of the files in my project. My codebase today is completely C++-based and I also have tests using cppunit. Here's my file structure of the GFL library (Windows dll): GFL/ include/ GFL <- headers go here src/ <- C++ source goes here (creates GFL.dll) Test/ <- cppunit tests go here (Test.exe links with GFL.dll) Now I need to create the python->C++ bridge using Boost.Python. This has to be separate from the GFL dll as I don't want to link with python in the main dll at this stage. Here's what I am thinking: GFL/ include/ GFL src/ Test/ PyBridge/ <- source files with Boost.Python bridge This would create two libraries, GFL.dll and GFL.PyBridge.dll. I am unsure of the naming convention. Now, I probably would put python test files in PyTest, like so: GFL/ include/ GFL src/ Test/ PyBridge/ PyTest/ <- nose tests here :-) What do you think about this structure? Anybody here doing similar things? I would really appreciate some feedback! :-) Now to another question (sorry if I am too off-topic on this one). We are using TeamCity for continuous integration. My goal is to integrate nose-tests using TeamCity. I can already vision how that would work. But I would also like to make GFL.dll and GFL.PyBridge.dll available to my integration&verification team, so that they can create their own python scripts for verification tests. Is there anyone here who has this kind of solution in place? If so, how do you make the compiled binaries easily available to the I&V team? If this is really too off-topic I'll take my question to the TeamCity forums (might do it anyway). Thanks in advance! Regards, Daniel Lidström Stockholm, Sweden ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] [Boost Python] Extended class loosing attributes when saving as pointer to BaseClass in C++
Hey,
My problem is the following:
I do have a C++ class, "BaseClass", that I am extending in Python
("SubClass"). Also there is another C++ class, let's call it
"BaseClassManager" which has a vector of BaseClass* (well, actually it's
holding shared_ptr's). Instances of "SubClass" are created in Python,
but ownership has been transferred to C++, as "BaseClassManager" holds
all the objects.
Here is the code that illustrates this:
Wrapped BaseClassManager
class_("GameBaseX")
.def("addObject", &BaseClassManager::addObject) // takes
shared_ptr< BaseClass>&
.def("getObjectByName",
&BaseClassManager::getObjectByName); // takes a string, returns
shared_ptr
WrapperClass for Base (needed for transferring ownership)
class BaseClassWrap : public BaseClass{
public:
BaseClassWrap( PyObject* self_, const std::string& name)
: BaseClass(name),self(self_) { Py_INCREF(self); }
BaseClassWrap( PyObject* self_, const BaseClass& copy ) :
BaseClass(copy), self(self_) { Py_INCREF(self); }
~BaseClassWrap() { Py_DECREF(self); }
PyObject *self;
};
Wrapped BaseClass
class_ >("BaseClass",
init())
.add_property("name", make_function(&BaseClass::getName,
return_value_policy()) );
// both needed for using shared_ptr's together with the wrapper-class
register_ptr_to_python >();// to_python converter
implicitly_convertible, shared_ptr >();
Subclass
class Subclass(BaseClass):
def __init__(self, name):
BaseClass.__init__(self, name)
self.foo = "bar"
--
Imagine the following Python code:
obj = SubClass("superclass")
BaseClassManager.addObject(obj)
# and somewhere else
obj = BaseClassManager.getObjectByName("superclass")
print obj.name # prints "superclass" as expected
print obj.foo # AttributeError: 'BaseClass' object has no
attribute 'foo'
Seems all attributes got lost, be it a member-variable or methods I
defined in SubClass. Strangely obj is in both cases the same pointer (f.
ex. "SubClass object at 0x02343345").
Is there something I can do to preserve the attributes? Otherwise it is
kind of senseless to extend a C++ class in Python if it can't have its
own attributes.
Thanks a lot for the help.
Cheers.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Boost Python] Extended class loosing attributes when saving as pointer to BaseClass in C++
I think I can explain what's going on, and I've got an idea for a
partial solution.
But first, try making BaseClassWrap multiply inherit from BaseClass and
boost::python::wrapper. That might fix everything. If not,
read on...
When boost::python converts a C++ value to Python, it looks up the C++
RTTI type name in a registry and finds a converter for that type. Those
converters generally make a new Python object, and put a
boost::python::instance_holder in it, containing a C++ object by value
or [smart] pointer. But what you want is to extract the PyObject* from
the C++ object and just incref and return that. I think you could do
this by writing your own Python version of BaseClassManager that checks
for this possibility:
object PyBaseClassManager_getObjectByName(
BaseClassManager & manager,
std::string const & name
) {
shared_ptr r = manager.getObjectByName(name);
shared_ptr w =
dynamic_pointer_cast(r);
if (w) {
handle<> h(w->self);
return object(h);
}
return object(r);
}
...unfortunately, you'd have to do that with ANY C++ function that
returns a shared_ptr. A better solution would be to write a
custom to-python conversion for shared_ptr, or if necessary a
custom ResultConverterGenerator to do that work, but that's a little
more complicated.
This is probably something boost::python should do automatically if
BaseClassWrap is a subclass of wrapper. If it doesn't, and
you can get me a complete example that demonstrates the problem, I'll
see about making a patch to make that happen.
Jim Bosch
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Boost Python] Extended class loosing attributes when saving as pointer to BaseClass in C++
Thanks for help! A better solution would be to write a custom to-python conversion for shared_ptr Tried it and works perfectly. Good hint! This is probably something boost::python should do automatically if BaseClassWrap is a subclass of wrapper. If it doesn't, and you can get me a complete example that demonstrates the problem, I'll see about making a patch to make that happen I'll have some free days in February so I'll put this into a small project for you to play around with, so the whole procedure can be made a little easier. Thanks a lot for your help! Cheers. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Please help: boost python 1.41 extension problem
Hi, I am trying to install boost 1.41 on Redhat Enterprise Linux 5.3 and I got problem with the extension test. Following the instructions here: http://www.boost.org/doc/libs/1_41_0/libs/python/doc/building.html - I built boost python using bjam. - cd into the libs/python/example/quickstart/ directory - bjam toolset=gcc --verbose-test test Now I see embedding test passes while extension test failed. I got the same problem with boost 1.35, 1.37 on Fedora 7. Below is the error messages: ../../../../boost/type_traits/detail/cv_traits_impl.hpp:37: internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:5067 Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla> for instructions. Preprocessed source stored into /tmp/ccIhs3ut.out file, please attach this to your bugreport. "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -fPIC -I"../../../.." -I"/usr/include/python2.4" -c -o "bin/gcc-4.1.2/debug/extending.o" "extending.cpp" ...failed gcc.compile.c++ bin/gcc-4.1.2/debug/extending.o... ...skipped extending.so for lack of extending.o... ...skipped test_ext for lack of extending.so... Does anyone encounter the same issue as me ? Anyone can help ? Thanks a lot, Yun ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
