Hi,

wow, that my code will actually get used.. :)

Contrary to my comment in the code of the first version, i now think that the member of the iterator and matrix_column_vector should not be a Matrix* or Matrix& but a Matrix::closure_type or Matrix::const_closure_type depending on whether Matrix is const or not. This resolves the dangling reference problem for temporary matrix_expressions completely.

with the current code and C++ 11 it is possible to write

matrix<double> A,B;
auto matVec = make_row_vector(A+B);

vector<double> crasher= matVec(0);//A+B is already destroyed.

which is not a good thing.

This is easy to fix, given the following meta-function:

template<class E>
struct closure{
typedef E::closure_type type;
};
template<class E>
struct closure<E const>{
typedef E::const_closure_type type;
};

and than replacing

Matrix& matrix_;

by

typename closure<Matrix>::type matrix_;

On 13.09.2013 15:31, Nasos Iliopoulos wrote:

Joaquim,
do you think you can request a pull of your code here?
https://github.com/uBLAS/ublas/tree/ublas_feature0011_mvrange_interface_t7411/

Also a test case is necessary. Please follow a style like that:
https://github.com/uBLAS/ublas/blob/ublas_feature0011_mvrange_interface_t7411/test/test_assignment.cpp
since it integrates well with boost's auto regression test functionality.

If you don't provide a test me or David will have to make one that will take more time.

-Nasos

On 08/17/2013 11:36 AM, Joaquim Duran wrote:
Hello all,

I've been used the matrix row/column range successfully. Also, I've modified the code of Oswin and I've generalized a little:

- Added reverse iterators.

- Resize of matrix

* From matrix_row facade the number of rows of the matrix could be changed but not the number of columns.

* From matrix_column facade the number of columns of the matrix could be changed but not the number of rows.

I would like to update the source code to ticked 7411 if there is no inconvenient for your part. I've followed the style of Oswin. Also, I've provided an executable but not tests cases, as Oswin did,

Joaquim Duran

2012/9/23 Gunter Winkler <guwi17@gmx.de>

Hello,

Am Saturday 22 September 2012 schrieb Oswin Krause:
> Hi,
>

> Here is my slightly adapted version of the range. I didn't find the
> boost coding guidelines so i just tried to fit it to other ublas
> headers(with limited success). Since i am not breathing standardese,
> I am not sure whether i am 100% correct in every aspect.
>
> Out of standard reasons, the implementation using proxy objects like
> matrix_row does not lead to a random_access_iterator even though it
> meets all traversal requirements. So algorithms like
> random_shuffle(and sort(?)) will work in practice but overeager
> compilers as for example MSVC will complain in debug mode. A
> solution to this is lying about the iterator category, but since i
> am a honest person, i don't ;)
>
> the implementation comes with a short test case, but i can also add a
> bit more if required.

see https://svn.boost.org/trac/boost/ticket/7411

@Joaquim: does this solve your problem?

mfg
Gunter

_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: jduran.gm@gmail.com
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: athanasios.iliopoulos.ctr.gr@nrl.navy.mil
_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: Oswin.Krause@ruhr-uni-bochum.de