[C++-sig] Re: My latest project
Neal D. Becker
ndbecker2 at verizon.net
Mon Aug 16 14:23:25 CEST 2004
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.
More information about the Cplusplus-sig
mailing list