
Boost : 
From: walter_at_[hidden]
Date: 20010919 05:29:10
 In boost_at_y..., Kresimir Fresl <fresl_at_g...> wrote:
> On Wednesday 29 August 2001 19:50, walter_at_g... wrote:
>
> > > > Thanks a lot. I incorporated most of your changes and compiled
> > > > with GCC 2.95.2. I hope, that we do not have to differentiate
> > > > between 2.95.2 and 3.0.
>
> Almost. Only remaining problem which I noticed is that the lines
>
> #ifdef USE_GCC
> namespace std {
> template<class I, class T>
> struct iterator {};
> }
> #endif
>
> in `iterator.h' must be deleted (or commented out) to compile with
3.0.1.
Fixed.
> (Also, there's no need for nonstandard definitions of `copy()' and
> `swap_ranges()' in `config.h'. Were they really needed for 2.95?)
Not absolutely. But there are a few differences in the STL
implementations of MSVC, GCC and BCC and this was a possible solution.
> > > There's one more thing which I noticed in my examples:
> > >
> > > matrix.h should include vector.h.
>
> > Will be done, thanks for the hint.
>
> Still pending ;0)
Sorry, done.
> There are some other missing includes:
>
> `vector_pr.h' in `matrix_pr.h'
> `matrix_pr.h' and `matrix.h' in `matrix_sp.h'
I'll have to reconsider the include dependencies.
>
> > > BTW, do you plan to add const versions of functions
> > > matrix<>::row(), matrix<>::column() and matrix<>::project()
> > > (which probably means introduction of corresponding
> > > types const_matrix_row<> etc.) ?
> >
[snip a first idea]
> I think that `const_vector_range_type' can be defined as:
>
> template<...>
> class vector {
> // ...
> typedef const vector<T, F, A> const_self_type;
> typedef const vector_range<const_self_type>
> const_vector_range_type;
> // ...
> };
>
> and used as:
>
> const numerics::vector<double> cv (v);
> typename numerics::vector<double>::const_vector_range_type
> cvr (cv.project (b, e));
>
> All legal (const) accesses are then possible.
Yes.
> (This is `VARIANT 1' of typedefs and functions that provide const
> projections  see below.)
>
> > I currently would not like to introduce classes like
> > const_vector_range, because that could result in more
> > source code or more complex template constructions.
>
> In fact, there's no need for new types (as I thought before).
> Classes
>
> vector_expression_range<>
> matrix_vector_unary1<>
> matrix_vector_unary2<>
> matrix_expression_range<>
>
> (which are return types of `global' project(), row() and column()
> functions) can be used as return types of const member
> functions:
>
> template <...>
> class vector {
> // ...
> typedef vector<T, F, A> self_type;
> typedef typename
> vector_expression_range_traits<self_type>::result_type
> const_vector_range_type;
> // ...
> const_vector_range_type project (const range& r) const {
> return numerics::project (*this, r);
> }
> // ...
> };
>
> I prefer this second variant; after all, these classes were
obviously
> designed to provide const projections.
This is another approach to implement const projections, but
expression templated projections are mainly designed to provide const
projections for expressions, for example project (a + b, 0, size).
IMO there are three reasons to implement const projections for
containers and proxies using your first approach:
 we currently can't use range composition with expression templated
projections
 compile times may slow down with expression templated projections
 expression templated projections seem to be slightly slower at
runtime
> Also, nonconst projection classes (vector_range<>,
> matrix_row<>, matrix_column<> etc.) can then be simplified.
> For example, there is no need for const and nonconst element
> access operators:
>
> template <...>
> class vector_range {
> // ...
> value_type operator () (size_type i) const {
> // One has do to this, to get the const member
dispatched?!
> const vector_type &data = data_;
> return data (r_ (i));
> }
> reference_type operator () (size_type i) {
> return data_ (r_ (i));
> }
> // ...
> };
>
> (Quoted comment points to the problem.)
The mentioned comment concerns problems with sparse access. I'm not
sure, whether these are really solvable with const proxies. I'll
think about it.
> Const version (which returns nonconst reference) suffices:
>
> reference_type operator () (size_type i) const {
> return data_ (r_ (i));
> }
>
> This is similar to iterators: derefence operator is const although
> it returns nonconst reference to some element of a sequence.
>
> I added const projection typedefs and functions to all (I hope)
> relevant classes. Diff files (with respect to the latest version
> in CVS) are attached, if you are interested.
Yes. We've incorporated an implementation using your first approach
and checked it in. Thanks.
[snip example]
> First variant does not work with canonical_vector<>
Fixed.
> and the
> second with banded_matrix<>;
banded_matrix was an early draft. We've updated it and provide a new
test.
> strange, it seems that in both
> cases the reason is that 'iterator' or 'const_iterator' are not
> defined.
>
> (Proposed changes to nonconst projection classes are not
> yet done.)
Regards
Joerg Walter
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk