Re: [C++-sig] create boost array from a Numpy PyArray without copying data?
On Monday 19 January 2009 07:16:10 Sebastian Walter wrote: > My question is: > How can I create a > boost::python::numeric::array from a Numpy Pyarray without copying data? See http://mail.python.org/pipermail/cplusplus-sig/2008-October/013825.html for a full solution. In particular, see the following class: template struct ublas_vector_from_numpy Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] create boost array from a Numpy PyArray without copying data?
On Tuesday 20 January 2009 04:27:02 Sebastian Walter wrote:
> Thanks for the hint :),
> Your code is a little to heavyweight for my purposes,
> but I learned quite a lot how boost::python converters work.
>
> And it also gave me the idea that finally solved my problem!
Good.
> // global to guarantee that the data is not freed after
> test_function_that_doesnt_copy returns
> double x[] = {1.,2.,3.};
In this case, you run into the problem of lifetime management. Unless you use
globals, how do you guarantee that once all users of the array are done with
it, the array is deleted? The array must be deleted from either the python
side (via numpy) or from the C++ side (by yourself). Handling this problem is
the cause for much of my code (which may still be too heavyweight for you).
Regards,
Ravi
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] create boost array from a Numpy PyArray without copying data?
On Wednesday 21 January 2009 03:40:00 Sebastian Walter wrote:
> Apparently I have to increase the refcount manually when I return a raw
> PyObject. So I wrote getter functions like that:
>
> PyObject* get_rhs(){
> return incref((PyObject *) _array_my_rhs);
> }
> I'm not sure that this is the way it should be done. But it solved the
> memory corruption problem.
In this case, you are essentially creating a memory leak. The returned array
will never be deleted by python since its reference count will never go to
zero. Please see http://blog.enthought.com/?p=62 for information on fixing
this issue. The code I pointed out earlier encapsulates this using a custom
deleter in C++ which can be used independently of ublas.
Regards,
Ravi
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] create boost array from a Numpy PyArray witho ut copying data?
On Thursday 22 January 2009 05:51:20 Sebastian Walter wrote: > In my above case I know that *x won't be deleted because it is global, > right? *x is not deleted since you used PyArray_SimpleNewFromData; that *x is a global is irrelevant here. > Why exactly does the > *** glibc detected *** python: malloc(): memory corruption (fast): > 0x0817b6a1 *** > occur then? In the code you posted this time, incref() is required so that someone owns a reference to the array object. What I don't know off the top of my head is whether you need an incref in the constructor of A and a decref in the destructor of A. > And is there a way to get the refcount of an object within Python? I'd > like to test if the refcount is correct. sys.getrefcount(obj) Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] create boost array from a Numpy PyArray without copying data?
On Friday 23 January 2009 04:44:43 Sebastian Walter wrote: > > In the code you posted this time, incref() is required so that someone > > owns a reference to the array object. What I don't know off the top of my > > head is whether you need an incref in the constructor of A and a decref > > in the destructor of A. > > This is also something I wondered about. > I guess it's better incref/decref them to be on the save side, right? IIRC, PyArray_SimpleNewFromData gives you a new reference. If that is correct, you will need to decref() it in the destructor of A so that python can clean up the numpy array (without touching your global data). What is the value of the flag NPY_OWNDATA after the call to PyArray_SimpleNewFromData? That should tell you whether python will attempt to free your global data structure. > --- test.py > from _test import * > import sys > > def test_my_array(): > a = A() > print 'a.my_array=',a.my_array > print 'sys.getrefcount(a)=',sys.getrefcount(a) > print 'sys.getrefcount(a.my_array)=',sys.getrefcount(a.my_array) > > > if __name__ == "__main__": > test_my_array() > > end test.py - > I get the output > > --- output - > > wal...@wronski$ python test.py > a.my_array= [ 1. 2. 3.] > sys.getrefcount(a)= 2 > sys.getrefcount(a.my_array)= 2 > > --- end output > > Ermm, is that good? > I expected that the refcount would be 1 and not 2. I don't know. I generally avoid these issues by writing custom converters and letting boost.python handle reference counting. Perhaps someone else on the list might be able to help. Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [boost] [Python] GSoC and Python 3.0 Support
On Wednesday 11 March 2009 12:38:55 Haoyu Bai wrote: > > 1. Thread safety > > 2. PyFinalize support > > 3. Easier methods to write to_python/from_python converters > > 4. Python 3.0 support > > 5. Ability to extend the fundamental PyTypeObject used by boost.python > > Thanks! Seems there's a lot of interesting. So would anyone willing to > mentor this? Sadly, I suspect that finding a mentor will be difficult (perhaps even more difficult than the actual project). Off the top of my head, the following folks come to mind: - Dave Abrahams - Stefan Seefeld - Ralf Grosse-Kunstleve - Roman Yakovenko You might try contacting them off list or on c++-sig (cc'ed on this email). > Also thanks Ravi for a list of features that may be candidates for > this project. I will dive into Boost.Python source code to see more > about these. I did not mean to imply that the features I requested should be part of your GSoC. Thread safety & PyFinalize support would each be worth a GSoC project just by themselves, IMHO. If you will be tackling python 3.0 support, it might be possible to combine it with greater support for embedding python since much of the work in both aspects would be about wrapping python C API for C++ programmers. Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Question regarding importing libraries to weave
On Thursday 14 May 2009 2:41:02 pm Magnús Bergur Magnússon wrote: > My name is Magnus and I am working as a software developer for a company in > Iceland. We use weave inline with python to boost our processing capacity. > However there is one factor that is limiting us. We cannot figure out how > to import libraries to Weave such as just or , what is > the right procedure for that? Also, what is the most effective tool for > text processing in python? We have been using weave inline and moving char > by char but is there a more effective way and could string.h speed things > up? This is not a boost.python question; I doubt we have very many users of weave here. You may have better luck asking on the numpy lists (numpy- discuss...@scipy.org). Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Details of Boost.Python Py_Finalize issue?
On Sunday 02 August 2009 11:44:22 Haoyu Bai wrote: > So could anyone share your experience with this issue, provide some > test case or anymore information about this issue? I will try to solve > it. I haven't been able to spend any time on this. But the general approach I wanted to check is as follows: Test 1 (to check registry operation): 1. Use an example which embeds (not extends) python. 2. Register a type X to be converted to C++ type XC. 3. Perform some operations to verify that step 2 works. 4. Call PyFinalize. 5. Restart python vising PyInit... 6. Check that X does not convert to XC. Test 2 (to check object cleanup): 1. Hold weak pointers to some shared_ptr objects exposed to python. 2. Call PyFinalize. 3. Ensure that all the weak_ptrs point to deleted objects. Let me think about this some more. Please try pinging Dave A directly to make sure he has no tests for you to try. Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Details of Boost.Python Py_Finalize issue?
On Thursday 06 August 2009 22:16:59 Haoyu Bai wrote: > > Test 1 (to check registry operation): > > 1. Use an example which embeds (not extends) python. > > 2. Register a type X to be converted to C++ type XC. > > 3. Perform some operations to verify that step 2 works. > > 4. Call PyFinalize. > > 5. Restart python vising PyInit... > > 6. Check that X does not convert to XC. > > > > Test 2 (to check object cleanup): > > 1. Hold weak pointers to some shared_ptr objects exposed to python. > > 2. Call PyFinalize. > > 3. Ensure that all the weak_ptrs point to deleted objects. > > > I have the attached file to check the two test cases you mentioned, or > see it at here: http://pastebin.org/7108 > > The test #1 failed. Registered converters are not cleaned up during > Py_Finalize. But test #2 not fail, shared_ptr object is properly > destroyed. You rock. There are more cases where data ought to be cleaned up, but I forget now. Let me look at some old custom converter code this weekend before I come up with more tests. > I think the registration issue is not hard to fix. But is the "crash" > mentioned in BPL manual still valid? We still can't produce any crash. The only way I can think of for this to happen is if boost.python holds some reference to an object held by the python interpreter before PyFinalize was called. The only candidate I could find is the fundamental PyTypeObject used by boost.python but nothing popped out on a cursory look, but then I doubt anyone can find bugs in Dave's code upon cursory examination :-) I am not sure that I can spend enough time on this prior to the end of your GSOC period. Apologies. Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] [python] Function objects in place of member functions
Hello,
If a free function 'func' has X* as its first argument, then, boost.python
allows it to be bound to a member function on the python side, i.e., the
following is legal:
void func( X* x, arg1_t arg ) { ... }
class_( "X" ).def( "func", &func );
In order to use a function object in place of a free function, one must
specialize/overload
boost::python::detail::get_signature
which, for some reason, does not account for function objects. Here's a very
simple example that works:
--
#include
struct X { int y; };
// Function object
struct Z { int operator()( X *x, int z ) { return z + x->y; } };
namespace boost { namespace python { namespace detail {
mpl::vector get_signature( Z&, X* )
{return mpl::vector();}
}}}
#include
#include
BOOST_PYTHON_MODULE( mft ) {
boost::python::class_( "X" )
.def( "z", Z() ).def_readwrite( "y", &X::y ); }
-
However, note that the overload of get_signature precedes the inclusion of the
boost.python headers, which is extremely inconvenient. However, if the headers
are moved to their proper location as in the following,
--
#include
#include
#include
struct X { int y; };
// Function object
struct Z { int operator()( X *x, int z ) { return z + x->y; } };
namespace boost { namespace python { namespace detail {
boost::mpl::vector get_signature( Z&, X* )
{return boost::mpl::vector();}
}}}
BOOST_PYTHON_MODULE( mft ) {
boost::python::class_( "X" )
.def( "z", Z() ).def_readwrite( "y", &X::y ); }
-
the compilation fails with the following error message (gcc 4.4.1 with boost
1.37 or 1.39):
$ g++ -Wall -shared -o mft.so memft.cc -lboost_python-mt -
I/usr/include/python2.6 -fPIC
In file included from memft.cc:1:
/usr/include/boost/python/class.hpp: In member function ‘void
boost::python::class_::def_impl(T*, const char*, Fn, const
Helper&, ...) [with T = X, Fn = Z, Helper =
boost::python::detail::def_helper, W = X, X1 =
boost::python::detail::not_specified, X2 =
boost::python::detail::not_specified, X3 =
boost::python::detail::not_specified]’:
/usr/include/boost/python/class.hpp:235: instantiated from
‘boost::python::class_& boost::python::class_::def(const char*, F) [with F = Z, W = X, X1 =
boost::python::detail::not_specified, X2 =
boost::python::detail::not_specified, X3 =
boost::python::detail::not_specified]’
memft.cc:16: instantiated from here
/usr/include/boost/python/class.hpp:536: error: no matching function for call
to ‘get_signature(Z&, X*)’
Why is the overloaded get_signature not picked up when it is declared *after*
the inclusion of the headers?
The reason for using function objects is to change the argument types of a
member function of X as seen by python; for example, the functor would have an
argument type 'double' and would then internally convert the received 'double'
argument from the python side into some custom type prior to passing it to the
member function of X. In other words, the functor would act as a C++
equivalent of a python decorator.
Regards,
Ravi
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [python] Function objects in place of member functions
On Sunday 11 October 2009 19:44:29 troy d. straszheim wrote: > > Why is the overloaded get_signature not picked up when it is declared > > after the inclusion of the headers? > > I'm not sure why it isn't picked up. Does that mean that you can reproduce the problem I pointed out? > I've been working in this area, > replacing most of detail/caller.hpp and detail/invoke.hpp with > boost.fusion, seen here: > > http://gitorious.org/~straszheim/boost/straszheim/blobs/python/boost/python > /detail/caller.hpp > > In the process, I overhauled get_signature to use boost::function_types, > and to be a metafunction, not a function: > > http://gitorious.org/~straszheim/boost/straszheim/blobs/python/boost/python > /signature.hpp IMHO, this is the right way to do it. This avoids relying on the compiler to optimize out all the ugly tag-dispatching. Of course, Dave A & Ralf WGK did not have function types when they wrote this originally. [snip] >boost::function bf0(fobj); Why do you need to use boost::function here? Shouldn't the type be deduced automatically? > I'm fairly new to the internals of boost.python, and only just now got > this working... Do you see problems with this, specifically the > conversion of get_signature from function to metafunction? I don't see any problems with the conversion of get_signature to a metafunction. Do compile times get any longer? Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [python] Function objects in place of member functions
On Monday 12 October 2009 08:47:22 troy d. straszheim wrote:
> >>boost::function bf0(fobj);
> >
> >
> > Why do you need to use boost::function here? Shouldn't the type be
> > deduced automatically?
> >
>
> Note that the .def() of the various boost::function objects work without
> requiring the user to specialize get_signature, (since this modified
> get_signature metafunction knows about boost::function objects).
[snip]
> I think interoperability with boost::function is a Good Thing, but in
> the example above (and the previous), all it does is give def() a way to
> tell what the signature of the function object is at compile time, and
> it does so at a runtime cost.
At least for my case, that extra virtual function call is a killer.
> A specialization of get_signature works,
> but strikes me as kinda ugly (it should at least be moved out of
> 'detail' if it is a user customization point). How about something like
>
>class_("T")
> .def("f1", f1, sig)
> .def("fi", f1)
I'd rather have something along the lines of
.def< mpl::vector >("f1",f1)
by using function_types to compose the currect function signature.
Alternatively, one could have the sig<> template above be a def_visitor and
take the appropriate template arguments without the need to modify class_::def
at all.
> >> I'm fairly new to the internals of boost.python, and only just now got
> >> this working... Do you see problems with this, specifically the
> >> conversion of get_signature from function to metafunction?
> >
> >
> > I don't see any problems with the conversion of get_signature to a
> > metafunction. Do compile times get any longer?
>
> I haven't checked this yet. I have other concerns re typechecking and
> automatic conversions...
Care to elaborate?
Regards,
Ravi
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Numpy ndarray as argument or return value using boost python
On Monday 12 October 2009 11:36:20 Pim Schellart wrote: > 1. Is boost python still maintained or should I switch to another tool. > 2. Is numpy supported, and if so, > 3. can someone give me a basic example of how to use it. Please see http://mail.python.org/pipermail/cplusplus-sig/2008-October/013825.html which supports numpy arrays with and without copying, along with pass by reference and pass by value. Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] How do I wrap a static member function?
Use class_.staticmethod(...) as shown below:
On Friday 30 October 2009 17:47:45 James Amundson wrote:
> BOOST_PYTHON_MODULE(foo)
> {
> class_("Foo",init<>())
> .def("doit", &Foo::doit)
.staticmethod( "doit" )
> .def("nonstatic_doit", &Foo::nonstatic_doit)
> ;
> }
Regards,
Ravi
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Python converters for raw pointers: request for help
On Friday 23 October 2009 04:38:30 Michele De Stefano wrote:
> typedef struct _p_Mat* Mat;
Creating a converter to/from a raw pointer is rather tricky (due to the way
argument type deduction handles pointers & references seamlessly, IIUC). You
should either expose _p_Mat or wrap the raw pointer in a struct and then
expose converters to it:
struct Mat { struct _p_Mat *ptr; };
If you come up with a better way, I'd be interested.
Regards,
Ravi
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [python] python + phoenix
On Wednesday 14 October 2009 21:59:42 troy d. straszheim wrote:
> boost::function still works, and doesn't require as<>:
>
>boost::function myplus = std::plus();
>def("myplus", myplus);
>
> and old-school function objects:
>
>def("otherplus", std::plus())
>
> I was surprised to find that it all plays nice with boost::phoenix:
>
>def("plus", as(arg1 + arg2));
>
>def("throw_if_gt_5",
>as(if_(arg1 > 5)
> [ throw_(std::runtime_error("too big!!")) ]
> .else_
> [ std::cout << val("okay")]));
>
> And boost::phoenix plays nice with shared_ptr, which plays nice with
> boost::python:
>
>struct X { int x; }; typedef boost::shared_ptr XPtr;
>
>class_("X")
> .def_readwrite("x", &X::x)
> .def("add7", as (arg1->*&X::x += 7))
> .def("add8", as(arg1->*&X::x += 8))
> .def("add9", as (bind(&X::x, arg1) += 9))
>;
>
> the other little thing is overload resolution, for which I propose a
> little helper function "unload" (underload? deload? resolve? I dunno):
>
>void foo(int);
>void foo(double);
>
>def("foo", unload(foo));
>
> Which is safer than
>
>def("foo", (void(*)(int)) foo);
>
> and just as safe as, and less verbose than
>
>void(*fooint)(int) = foo;
>def("foo", fooint);
>
> So that's where I'm at... what do you make of that interface?
This is very cool and pretty intuitive. My main concern is that one needs to
build up the function type in generic code (as opposed to mpl vectors), but we
do have function_types to help us.
You are going to have to propose this as several small patched, before Ralf &
Dave agree to it.
Regards,
Ravi
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [python] python + phoenix
On Saturday 31 October 2009 01:24:16 troy d. straszheim wrote:
> I take it that you have a use-case where it is difficult to specify
>
>as(thing)
>
> and easy to specify
>
>as >(thing)
>
> Could you elaborate?
I have some code that takes member function pointers of the form
R Obj::*( A1, A2, A3, ..., An )
and converts them to a function object Q with the following signature:
Rnew Q( Obj&, B1, B2, ..., Bn )
where
Rnew = result_conversion_metafunction::type
Bi = arg_conversion_metafunction::type
and Q is exposed via boost.python as a member of Obj.
For example, Ai could be a fixed-point number, with Bi being a double so that
the python side does not know anything about fixed-point numbers. An instance
of Q would convert eh floating point numbers passed from the python side into
fixed-point numbers, call the member function, and convert the returned value
to a double for use on the python side.
For these "converters", metafunctions from boost.function_types are used to
obtain the mpl::vector specifying result type and argument types. Extending
the technique above to function objects which take Obj* as their first
argument, I have a protocol which relies on the presence of a typedef called
'components' in the function object so that I can use the converter when
exposing via boost.python:
struct my_functor {
typedef mpl::vector components;
R operator()( Obj*, A1, A2, A3, A4 ) { ... }
};
// my_converter uses the components typedef
typedef typename my_converter::type Q;
Q q;
class_( "Obj" )
.def( "my_func", q )
;
Regards,
Ravi
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] function types as user-defined converters
On Friday 06 November 2009 14:52:49 troy d. straszheim wrote:
> Currently, the converter type still leaks out to python in the signature:
>
> class S(Boost.Python.instance)
> | add(...)
> | add( (S)arg1, (object)arg2) -> None :
> |
> | C++ signature :
> | void add(S*,to_optional
> (*)(boost::python::api::object))
>
>
> converters won't nest:
>
>def("foo", as(&somefn)); // nah
>
> I dont have a mechanism for hooking a user defined converter into the
> return type. I'm going to have to think about that one a bit more.
Did you have any ideas on this, Troy? This is the last bit I think I'd need in
order to replace my code with yours.
Regards,
Ravi
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost python calling conventions support patch submission (__stdcall, __cdecl, __fastcall)
On Tuesday 05 January 2010 12:26:27 Nicolas Lelong wrote: > Is this mailing list the best route to submit this patch, what more work > should be done to get it accepted into trunk ? Please file a trac ticket at svn.boost.org so that this does not get lost. Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Conversion of python files to C++ ostreams
Hi Troy, On Sunday 04 April 2010 16:16:46 troy d. straszheim wrote: > The boost.python code behind this is > in a separate repository, here: > >git://gitorious.org/~straszheim/boost/straszheims-python.git > > The code has diverged quite a bit from trunk boost.python by now. > I was only playing with your use case, tossing my results out there. > Ravi and I discussed the as<...> interface at length on this list some > time ago, and I've recently resumed playing with it. I am quite concerned about the divergence. How could I help integrate your changes back to trunk? As far as I am aware, neither Dave A nor RWGK have expressed any interest in these changes, and I am worried that all this work will be for nought. You are doing quite a bit of work with boost.python but I am worried that everything will stay as patches (sort of like Niall Douglas' thread-safety patches). Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Advice sought on making a large C++ application a Python extension
On Monday 06 September 2010 08:15:39 David Aldrich wrote: > I have only looked at the boost.python tutorial that demonstrates a 'Hello > world' Python extension. For our project we would be dealing with > something very much bigger, with many classes, singleton classes and > (possibly) global data. My question is, would it be practical to make all > of those entities Python extensions? Yes. PyOGRE or cctbx are excellent exmples of larger projects which use boost.python. You may want to use py++ to automate binding generation to save yourself quite some time. > We would also want to continue to support the application as a wholly C++ > application. Currently, we use gnu make to build it. Would I have to > add a parallel build system using bjam to build the extensions? And then > maintain both make's makefiles and bjam's Jamroot files? No. The python modules can be compiled using regular make. My recommendation is to avoid using bjam, even if it is technically superior, as it is not used widely enough to have the critical mass that other tools (autotools, cmake, scons) have which means that finding help is pretty painful (as there seem to be only a couple of people with knowledge sufficient to answer any non-trivial questions). > Can .pyd files be loaded by the C++ linker? These are simply shared libraries (on POSIX). So the linker can read them. Avoid storing the python bindings in the same shared libraries as your core code since the coupling will be hard to undo while gaining nothing. Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] wrap C++ function with private copy constructor
On Wednesday 13 July 2011 07:19:44 Manuela Kaelberer wrote: > I have to wrap a C++ API for Python. There are a couplt of difficulties: > - The C++ classes have private constructors. Use boost:python::no_init in class_<...>. > - pointers to class instances are parameters for functions This is not a problem since boost.python handles pointers and references in function parameter lists automatically. > - callbacks that are initiated by the C++ side, but call functions > implemented on the Python side. This is a little tricky but is well-covered in the documentation: http://www.boost.org/doc/libs/1_47_0/libs/python/doc/tutorial/doc/html/python/exposing.html#python.virtual_functions_with_default_implementations Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [Boost.Python v3] Features and Scope
On Friday 26 August 2011 16:39:11 Jim Bosch wrote: > > Well, speaking for myself, mostly time. I'd be inclined to do a rewrite > > along the lines of the langbinding ideas if I had time. > > I had only been vaguely aware of langbinding until I followed up on your > last email. It's a very nice separation, though after bad experiences > using SWIG I am a little wary about trying to build a one-size-fits-all > front-end for different languages. Is code for boost.langbinding available anywhere? Or is it currently only a design description? Regards, Ravi ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
