Boost logo

Boost :

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-10-07 10:36:32

On Sunday 06 October 2002 15:38, Kresimir Fresl wrote:
> > From the iterator_adaptor discussion, I learned that indeed 1 does not
> > have to compile (if a ublas::vector is like a std::vector where
> > operator[] is only required to return a type tha is convertible to T).
> I am afraid that you got it wrong.

you're right, thanks for correcting me.

> For more details on why and when it works (and also why
> and when some other solutions do or don't work) see the
> thread `ublas interoperability' in boost-ml.

I've synced with this discussion and in combination with my own experience, I
think the member data() is not going to solve our problems.

First, data() on a vector_range< vector< double > > returns data_ of the
vector_range which is a reference to the vector< double >.

A function which thus takes a vector(_range/_slice) as a template argument,
can't rely on data() to provide the 'container'.

I therefor, I my private copy, added a member array() which for a vector<
double > is the same as data(), but for vector_range for instance returns

(this is also not perfect since &*array().begin() on a vector_range will not
point to the first element in the vector_range but to the first element in
the underlying vector ;(

Anyway, I think we'll never be able to use the current members (such as
data()) to recover the underlying pointers. IMO we should just add a member
to all ublas classes which keep track of the underlying pointers (such as the
above array() does)


Boost list run by bdawes at, gregod at, cpdaniel at, john at