Re: [eigen] why does the result of the col member function behave so different? |

[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]

On 05/07/2011 12:45:36 PM, Gael Guennebaud wrote:
> > By the way, I did "solve" this problem in my own matrix class by
> having
> > a special L_Vector class which is returned by slicing functions/
> > operators. This L_Vector class represents a temporary Lvalue, it
> has
> no
> > own storage but refers to storage elsewhere (like a column of a
> matrix)
> > Now, I do have
> > istream& operator>>(istream&, const L_Vector&)
> > but that's no problem, since it matches such Lvalue vectors (or
> > L_Matrix, rsp) only. I have used the same with my operator= .
>
> Yes our .col(i) method also returns a proxy object, and as I said you
> could also declare your operator >> with a const ref as you did for
> your own matrix class.
>
> However this is not safe regarding constness, e.g.:
>
> void foo(const Matrix& mat) {
> data >> mat.col(i);
> }
>
> will work while it should not!
>
Hi Gael, I think there is a solution. Translation my solution to
Eigen's language,
the trick is to have two versions of the col method, e.g. (without
details, templates,...)
ColXpr col(int c) {
....
}
AND in addition
ConstColXpr col(int c) const {
}
Now it is safe to use
istream& operator>>(istream&, const ColXpr&)
since this wouldn't be considered for overloading in case of
const MatrixXd A(r,c);
cin >> A.col(0); // this fails since there is no operator>> taking a
ConstColXpr as second argument.
Helmut.