|
|
Ublas : |
Subject: Re: [ublas] Matrix with vector interface.
From: oswin krause (oswin.krause_at_[hidden])
Date: 2013-09-14 06:28:50
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 <guwi17_at_[hidden] <mailto:guwi17_at_[hidden]>>
>>
>> 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_at_[hidden] <mailto:ublas_at_[hidden]>
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to: jduran.gm_at_[hidden] <mailto:jduran.gm_at_[hidden]>
>>
>>
>>
>>
>> _______________________________________________
>> ublas mailing list
>> ublas_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/ublas
>> Sent to:athanasios.iliopoulos.ctr.gr_at_[hidden]
>
>
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: Oswin.Krause_at_[hidden]