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

[Helmut Jarausch <jarausch@xxxxxxxxxxxxxxxxxxx>]

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.