|
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk