[C++-sig] Raw constructor (i.e. combination of make_constructor and raw_function)

[Hans Meine]

On Thursday 25 August 2005 02:07, Ralf W. Grosse-Kunstleve wrote:
> I recommend against doing it that way. It is not compatible with the C++
> interface:
>
> std::vector<double> a(1, 2);
>
> initializes a vector of size 1 with a value of 2.

OK, you're right.  I think it's a little bit misleading because I made up this 
testcase.  My original work was on a 'Pixel' class for images with possibly 
multiple bands, so I like to write Pixel(red,green,blue) and not 
Pixel([red,green,blue]).

> Here is a full wrapper which works that way:
>
> http://cvs.sourceforge.net/viewcvs.py/cctbx/scitbx/include/scitbx/stl/vecto
>r_wrapper.h?view=markup

Thanks.  BTW: For another vector-like class (Polygons consisting of points), I 
already chose your proposed interface.  I tried vector_indexing_suite, but 
it's __getitem__ was around 100 times(!) slower than that of a python Polygon 
class storing a list of points!  I found out that this is due to:
- the support for slices (probably not very much slower)
- the fact that python lists are optimized and already contain wrapped 
objects, whereas boost::python has to wrap each return value
- the fact that vector_indexing_suite *proxies* the entries (IIUC, and then 
this is surely the biggest slowdown).

Can you make a guess on the vector_wrapper performance in that respect?
(I can live with a *small* slowdown on __getitem__ which is evened out 
elsewhere by much faster C++ algorithms like length() of a polygon.)

Thanks again for your scitbx-links, I will try them out for my next 
vector-like class.  Concerning my Pixel class, I will probably add some 
__init__s of varying arity (up to e.g. 5) by hand.

-- 
Ciao, /  /
     /--/
    /  / ANS