Re: Matrix with vector interface.

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>::typematrix_;

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 <[email protected] <mailto:[email protected]>>
>>
>>     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
>>     [email protected] <mailto:[email protected]>
>>     http://lists.boost.org/mailman/listinfo.cgi/ublas
>>     Sent to: [email protected] <mailto:[email protected]>
>>
>>
>>
>>
>> _______________________________________________
>> ublas mailing list
>> [email protected]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to:[email protected]
>
>
>
> _______________________________________________
> ublas mailing list
> [email protected]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: [email protected]