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

[Nicodemus]

Ralf W. Grosse-Kunstleve wrote:

>I'll try a very brief summary of my array wrappers:
>
>- The simplest approach: mapping from C++ containers to Python tuples and vice
>versa. Main support header:
>http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/boost_python/container_conversions.h?view=markup
>
>- The most comprehensive approach: fully loaded boost::python::class_<> based
>N-dimensional arrays including all arithmetic (+-*/%) and boolean (<>=<=>==!=)
>operators, math functions (sin, cos, floor, etc.), selection facilities
>(generalized slicing) and full+fast+portable pickle support. The same Python
>type can be converted to 20+ different but related C++ types; e.g. if the
>multi-dimensional Python array is in fact just a 1-dim array it can be
>converted to a 1-dim C++ type. -- This system is quite a beast. Compiling the
>complete wrappers for the element type double takes about 45 seconds under
>Redhat WS 3, 3GHz Xeon. Now consider that I also have wrappers for bool,
>complex_double, float, int, long, size_t, std::string and a "vec3<double>" type
>(triple of three doubles), plus a few domain-specific types.
>http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/array_family/boost_python/
>
>- A simplified array wrapper for a reference-counted 1-dim array type, similar
>to the vector indexing suite, but with a few extras to cooperate with the
>"comprehensive wrappers" above, and a few omissions to keep compile times down.
>http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/array_family/boost_python/shared_wrapper.h?view=markup
>
>- Simple wrappers for std::vector, std::set, std::map. Designed as thin as
>possible to keep compile times down.
>http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/stl/
>
>I am not sure how much any of this generalizes. I guess container_conversions.h
>could be useful in many contexts, but the compromises I made in implementing
>the other approaches may not work well in other environments. I am posting the
>links here only as potential sources of ideas, for people who are not afraid of
>looking at raw code.
>  
>

Ralf,

Thanks for the summary. I have looked at the code and it looks good; I 
might use some of those ideas on my own code. But what I meant earlier 
were which approaches you usually take to keep the compile time down; I 
expressed myself poorly, sorry.

Best Regards,
Nicodemus.