[C++-sig] boost::* standard python conversions

[Ralf W. Grosse-Kunstleve]

--- "Preston A. Elder" <prez at neuromancy.net> wrote:

> I wonder, is there any concentrated task to convert parts of boost that
> make sense to have appropriate python wrappers?

I am not aware of a concerted effort to wrap parts of boost.

I've done a few more or less general wrappers myself:

boost::rational:

 
http://cvs.sourceforge.net/viewcvs.py/cctbx/boost_adaptbx/rational_ext.cpp?view=markup

  I think this is fairly complete, but the hash support could need more
attention.

Wrappers for std::vector, std::set, std::map:
  http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/stl/

  I made an attempt to keep these as simple as possible to minimize compile
times and extension module (i.e. .so or .dll) sizes.

Simple application of the Mersenne twister (random number generator) in boost:
 
http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/array_family/boost_python/flex_random.cpp?view=markup

There is also some general support for mapping C++ containers to Python tuples,
and Python tuples, list, ranges and iterators to C++ containers:

 
http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?rev=1.13&view=auto

  The end-user interfaces are at the bottom of the file and very easy to use,
i.e.

    tuple_mapping_variable_capacity<std::vector<your_type_here> >();

  The compile-time required for tuple mappings is signficiantly less than that
required for a fully-blown boost::python::class_<> based wrapper (because the
standard Python tuple facilities are reused). It is not suitable for large
arrays though because of the copy overhead (from a native C++ container into a
tuple or from a Python sequence into a C++ container).

In my experience as a scientific application developer, when it comes to
wrapping C++ containers there is not a general one-size-fits-all solution.
Compile times and extension module sizes for fully loaded
boost::python::class_<> based container wrappers are significant. I am actively
using four or five different approaches, depending on the usage patterns.
Hopefully in ten year, when computers are again 10 times faster and everybody
as 32GB of RAM or more this will be a non-issue and we can simply throw in a
general solution for everything, even if the conversions are not used very
much. However given current technology I find it necessary to decide
case-by-case what is the best balance of compile-time/extension module size vs.
run-time performance.

Cheers,
       Ralf



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250