$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: jhrwalter (walter_at_[hidden])
Date: 2001-12-11 05:13:16
--- In boost_at_y..., Toon Knapen <toon.knapen_at_s...> wrote:
> jhrwalter wrote:
[snip]
 
> >>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 ;-)
Yep. For the same reason, I'd like to deprecate range construction 
with the signature 
 
matrix_range<matrix<double> > mr (m, 0, i, 0, i);
 
also, do you remember that discussion? These functions usually do not 
affect the innermost loops, so optimizations shouldn't change these 
interfaces IMO.
 
BTW, another duplicated interface is element access: here we support 
for a matrix m the function like m (i, j) and array subscription m 
[i] [j] (using a proxy object). If we'd have to deprecate one of 
these, I'd tend to array subscription, because it usually does affect 
innermost loops.
 
[snip]
 
> >>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 ?
 
Tracing the call stack: first 
 
NUMERICS_INLINE
reference_type matrix::operator () (size_type i, size_type j) const {
    return data_ [functor_type::element (i, size1_, j, size2_)]; 
}
 
in matrix.h and then
 
NUMERICS_INLINE
reference_type unbounded_array::operator [] (size_type i) {
    check (i < size_, bad_index ());
    return data_ [i];
}
 
in storage.h, for example. Finally, there is a check ;-)
 
Regards
 
Joerg