uBLAS: Can I make my vector<...> derived class 'copy constructible' ?

Hi Joerg, or anyone who can help! As I am still on my spline templates, I came on to the following beast: template<class T> struct index_vector : public vector<std::pair<T, vector<ublas::vector<T>::size_type> > > {}; This should be an index vector that relates to a double (first) a vector of indices (second) which happens to be different for each 'first'. So far so easy. I can say: index_vector<double> IY; IY.resize(5); IY[0].first = 3.14; IY[0].second.reset(vector<double>(3)); IY[0].second[2] = 1; But I cannot: index_vector<double> IZ(IY); or index_vector<double> IZ; IZ = IY; or IZ.reset(IY); This compiles, but gives me runtime assertions because of size mismatches. I think my derived class is not 'copy constructible' and 'assignable'. Is there a simple way to fix this? (I am not even sure whether this is a uBLAS matter. So please simple tell me, and I will try to learn the missing parts.) Thank you, Roland

Hi Roland, you wrote:
As I am still on my spline templates, I came on to the following beast:
template<class T> struct index_vector : public vector<std::pair<T, vector<ublas::vector<T>::size_type> > > {};
This should be an index vector that relates to a double (first) a vector of indices (second) which happens to be different for each 'first'. So far so easy.
I can say:
index_vector<double> IY; IY.resize(5); IY[0].first = 3.14; IY[0].second.reset(vector<double>(3)); IY[0].second[2] = 1;
But I cannot:
index_vector<double> IZ(IY);
or
index_vector<double> IZ; IZ = IY;
or IZ.reset(IY);
This compiles, but gives me runtime assertions because of size mismatches.
Yes. The following mix of std::vector and ublas::vector seems to work for me under GCC 3.2.1: ---------- #include <vector> #include <boost/numeric/ublas/vector.hpp> using namespace std; using namespace boost::numeric; template<class T> struct index_vector : public vector<std::pair<T, ublas::vector<typename ublas::vector<T>::size_type> > > {}; int main () { index_vector<double> IY; IY.resize(5); IY[0].first = 3.14; IY[0].second.reset(ublas::vector<std::size_t>(3)); IY[0].second[2] = 1; index_vector<double> IZ1(IY); index_vector<double> IZ2; IZ2 = IY; } ---------- Do you need ublas algorithms for the outer or the inner vector? Otherwise you could use std::vector instead.
I think my derived class is not 'copy constructible' and 'assignable'. Is there a simple way to fix this?
I believe yes: we could drop the requirement that assignments have to be size conformant. But this requirement is pretty useful when doing basic linear algebra IMHO. So I'd like to hear other opinions...
(I am not even sure whether this is a uBLAS matter. So please simple tell me, and I will try to learn the missing parts.)
It's definitely an ublas matter: should we increase standard compatibility or stay with the size conformance restriction. Best, Joerg

Hi Joerg,
I think my derived class is not 'copy constructible' and 'assignable'. Is there a simple way to fix this?
I believe yes: we could drop the requirement that assignments have
to be
size conformant. But this requirement is pretty useful when doing basic linear algebra IMHO. So I'd like to hear other opinions...
Thank you, this will work for me. But still a question left: It seems even when I use the copy constructor of a ublas::vector the values are copied using the assignment operator. Shouldn't they be copied using their copy constructor instead? In this case also ublas::vector would work as same as std::vector. It is meaningful, when the operator= would not work since the contained vectors of course are not the same size. This problem will arise whenever doing 'vector of vector' or similar.
(I am not even sure whether this is a uBLAS matter. So please simple tell me, and I will try to learn the missing parts.)
It's definitely an ublas matter: should we increase standard compatibility or stay with the size conformance restriction.
I think vector is copy constructible, if the element type also is copy constructible, isn't it? And if I use a vector as a element type (which is copy constructible I think), there should be no problem. No need to give up current size conformance restriction behaviour for assignment. What do you think? Regards, Roland
participants (2)
-
jhr.walter@t-online.de
-
speedsnaii