From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2001-12-10 10:59:11
jhrwalter wrote:
> --- In boost_at_y..., Toon Knapen <toon.knapen_at_s...> wrote:
>
>>>This is indeed an alternative. matrix_range should be an suited
>>>submatrix adaptor (with a poor name?).
>>>
>>
>> > [and in another thread]
>> > matrix_range is well suited to address a sub matrix of an
>>
> existing
>
>> > matrix. But one has to consider carefully, what code a compiler
>>
> emits
>
>> > with this additional indirection, AFAIK
>>
>>
>>but matrix_range does not feature a resize(size_type,size_type).
>>The idea would be that you can constantly resize the adaptor
>>(matrix_range) as long as it is smaller or equal in size to the
>>
> matrix
>
>>it originates from.
>>
>
> I usually construct a new adaptor, for example:
>
> matrix<double> m (size, size);
> for (int i = 0; i < size; ++ i) {
> matrix_range<matrix<double> > mr (m, range (0, i), range (0, i));
> ...
> }
OK. (maybe a real resize might be faster although it's better to first
prove that there is a performance diff, 'early optimisation is the root
of all evil ;-)
>
>
>> > [and yet in another thread]
>> > Correct. matrix_range checks it's dimensions against the
>>
> dimensions
>
>> > of the underlying matrix.
>>I can't find that, the constructors e.g. looks like :
>>
>> NUMERICS_INLINE
>> matrix_range (matrix_type &data, const range &r1, const range
>>
> &r2):
>
>> data_ (data), r1_ (r1), r2_ (r2) {}
>>
>
> Oops. The checks are deferred until element access or iterator
> dereference. Is that too late?
can't find the check there either (I just ask because I'm trying to
understand all sources)
e.g. :
in matrix_range class
NUMERICS_INLINE
reference_type operator () (size_type i, size_type j) {
return data_ (r1_ (i), r2_ (j));
}
no check here ?