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
data_.array().
(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)
toon