Re: numeric/ublas & gcc 3.0

From: walter_at_[hidden]
Date: 2001-08-29 12:50:56

--- In boost_at_y... <mailto:boost_at_y...>, Kresimir Fresl < fresl_at_g... 
<mailto:fresl_at_g...>> wrote:
> On Monday 27 August 2001 20:32, walter_at_g... wrote:
> 
> > Kresimir Fresl wrote:
> 
> > > I attached the diff files. Maybe they can be useful.
> 
> > 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. We'll check the new version into CVS ASAP.
> 
> Please note that I hacked the templated types in declarations 
> of `prec_prod' in matrix_et.h (which were obviously result of 
> bad cut&paste) just to make tests compile; it's possible 
> that that's not what you intended. 
 
Yep. 

> 
> There's one more thing which I noticed in my examples: 
> 
>     matrix.h should include vector.h. 
> 
> Otherwise, if one uses only matrix.h (without previous inclusion
> of vector.h), `forward' and `backward' remain undefined.

Will be done, thanks for the hint.
 
> 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.) ? 

To understand the problem (and its consequences :-) I wrote a little 
sample. Here is a mutable vector range
 
    numerics::vector<double> v1 (1);
    numerics::vector_range<numerics::vector<double> > vr1 (v1.project 
(0, 1));
    vr1 (0) = 0;
    std::cout << vr1 (0) << std::endl;
 
To get const correctness, you would like to write 
 
    const numerics::vector<double> v2 (v1);
    // numerics::vector_range<const numerics::vector<double> > vr2 
(v2.project (0, 1)); // Compile time error: 2 overloads have no legal 
conversion for 'this' pointer

which is currently not possible. So if we extend
 
class vector {
        // other stuff...
 
        typedef const vector<T, F, A> const_self_type;
        typedef vector<T, F, A> self_type;
        typedef vector_range<const_self_type> const_vector_range_type;
        typedef vector_range<self_type> vector_range_type;
 
        const_vector_range_type project (size_type start, size_type 
stop) const;
        vector_range_type project (size_type start, size_type stop);
        const_vector_range_type project (const range &r) const;
        vector_range_type project (const range &r);
        
        // more stuff...
};

the vector range is definable
 
    const numerics::vector<double> v2 (v1);
    numerics::vector_range<const numerics::vector<double> > vr2 
(v2.project (0, 1)); 
    // vr2 (0) = 0; // Compile time error: Conversion loses qualifiers
    // std::cout << vr2 (0) << std::endl; // Compile time error: 
Conversion loses qualifiers

but access to the range does not compile. However a const vector range
 
    const numerics::vector<double> v3 (v1);
    const numerics::vector_range<const numerics::vector<double> > vr3 
(v3.project (0, 1));
    // vr3 (0) = 0; // Compile time error: left operand must be l-
value
    std::cout << vr3 (0) << std::endl;

should give us some kind of const correctness. 
 
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.
 
Regards
 
Joerg