[C++-sig] Re: My latest project

[Neal D. Becker]

David Abrahams wrote:

> Neal Becker <ndbecker2 at verizon.net> writes:
> 
>> OK, I agree the previous version sucked.
> 
> I wouldn't go that far.
> 
>> Here is a new one I think is much
>> better.
>>
>> The boost-python code is simple, and I'm not including it.  The
>> harder part is to supply the underlying c++ library for doing the
>> vector-vector and vector-scalar arithmetic.  I think I have a pretty
>> good design for that, which I'd like to share.
> 
> I think you're posting in the wrong forum then.
> 

Vector processing is in my view one of the primary interests for
boost-python.  By processing vectors, the overhead involved with python and
the python-c++ interface becomes acceptable.

I believe a suitable container for interfacing between python and c++ is of
fundamental interest to the boost-python community.  I'm sure there must be
a lot of interest in this subject.

I have tried to investigate 3 candidates.

1) std::vector
2) ublas
3) numarray

So far the results are:

1) std::vector - 
pros:
universal availability
easily understood
supports required operations (insert, erase...)
vector_indexing_suite already implemented (could be optimized more)

cons:
lacks vector arithmetic - but I just implemented this and it isn't difficult
even for an amateur like myself

2) ublas:
pros:
already has vector arithmetic

cons:
lacks required operations (e.g., erase)
no indexing_suite (see above)

3) numarray
pros: ?

cons:
I had a hard time finding documentation.
Heavy-weight interface -> high learning curve


Summary:
It appears that std::vector is a good choice.  Ublas might be better in the
future, but at present it lacks some required functionality.  A ublas
vector does not fulfill all the requirements of Sequence.  This topic is
known to ublas developers and may be addressed in the future.


> I have only 2 quick comments in this one:
> 
> 1. You should never use std::[binary|unary]_function because it
>    suppresses EBO.  Consider what happens when you have a
>    compressed_pair<minus<int>,plus<int> >.

OK.  I assume this means "Empty Base Optimization?"

> 
> 2. Isn't something appropriate already present in uBlas?
> 

See above.