Re: [boost] ublas: g++ 3.1 & como

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-05-02 15:43:12

----- Original Message -----
From: "Kresimir Fresl" <fresl_at_[hidden]>
To: "Joerg Walter" <jhr.walter_at_[hidden]>; "boost" <boost_at_[hidden]>
Sent: Thursday, May 02, 2002 11:05 PM
Subject: Re: [boost] ublas: g++ 3.1 & como

> Hi Joerg,
>
> >>These changes (as well as those from my previous post)
>
> > Did I miss any of your previous changes?
>
> No. It was a typo -- it should be `my previous posts' (plural),
> referring to all patches for g++ 3.0, 3.0.1, etc.
> that I posted earlier.

Good to know :-)

> >>To compile with `como', I used settings for g++, ie. I simply
> >>added in `config.h':
> >>---------------------------------------------------------------------
> >>107a108,112
> >> > #ifdef USE_COMO
> >> >
> >> > #define USE_GCC
> >> >
> >> > #endif
> >>---------------------------------------------------------------------
>
> > This seems arguable: you try to compile ublas under COMO with GCC
> > specific deviations. IMO it would be preferable to insert a separate
> > USE_COMO block into config.h.
>
> I agree. It was just a quick & dirty provisional trick, because separate
> USE_COMO block in `config.h' is not enough -- `#ifdef USE_GCC' in
> all files should be checked, and, if necessary, changed to
> `#if (defined USE_GCC) && (defined USE_COMO)' or something
> similar. Maybe one day, when I'll have time ... ;o)

I'm already trying to get a Comeau environment nearby ;-)

> >>[[`non_zeros_' must be `mutable' in `sparse_vector_of_sparse_vector'
> >>because const function `non_zeros()' (lines 998-1003) modifies it.]]
>
> > The intended functionality in
sparse_vector_of_sparse_vector::non_zeros() is
> > achieved, if we declare a local
> >
> > size_type non_zeros = 0;
> >
> > and add the sizes of the rows/columns to it. Then the member non_zeros_
> > doesn't need to be mutable.
>
> If I understand correctly, there's no need for `non_zeros_' member then?

Yep, but we could check the actual number of non zeros against the limit one
day.

> >>`como' also complains that
> >>
> >>    "/home/krcko/include/ublas/iterator.h", line 519: error:
> >>           identifier "base" is undefined
> >>
> >>patch for `iterator.h' is:
> >>-----------------------------------------------------------------------
> >>24c24
> >>< #ifdef USE_GCC
> >>---
> >> > #if (defined USE_GCC) && (!defined USE_COMO)
>
> As I incorrectly ;o) made USE_COMO equal to USE_GCC,
> this guard removes redundant definition of `struct iterator<>'.
>
> >>506a507,509
> >> > #ifdef USE_COMO
> >> >         using std::reverse_iterator<I>::base;
> >> > #endif
> [...]
>
> > This is a change I simply do not understand. Do you have any
explanation,
> > why it is necessary to use the 'using' directive under COMO? IOW could
this
> > be a COMO deficiency?
>
> I must admit that I am not sure that I understand it myself.
> (BTW, what does `IOW' mean?)

In other words, AFAIK ;-)

> `como' has `strict' (ie. ANSI) and `non-strict' mode of compilation. Only
> the `strict' mode needs the `using' directive (but guard in line 24 is
> of course needed in `non-strict' mode, too).
>
> Some time ago I asked them about a similar problem.
> To make the long story long ;o) I'll quote some parts from my letters
> and from their replies.

[snip Comeau's exegesis of the standard]

Incredible, I'll have to study this at weekend.

> To return to your letter:
>
> > I'd also prefer to write instead
> >
> > std::reverse_iterator<I>::base () += n;
> >
> > for example (libraries should be deliberate in using 'using' directives
> > AFAIK). Does this work for COMO?
>
> Yes, it works. But one needs only one `using' directive per class,
> and I am a lazy person ;o)
>
> They suggest
>
>      this->base() += n;
>
> which, we needn't be surprised, also works.
>
> BTW, some time ago `rwgk' posted the patch with `this->base()'
> for EDG compiler. His message can be found at:
>
>      http://aspn.activestate.com/ASPN/Mail/Message/1158300

Yuk, I looked up this thread again. Sorry, Ralf, that I missed this detail
completely :-(

> >>And finally, there are some missing includes in `traits.h':
>
>>--------------------------------------------------------------------------
> >>19a20
> >> > #include <cmath>
> >>20a22
> >> > #include <iterator>
>
>>--------------------------------------------------------------------------
> >>[[<cmath> is needed for `std::fabs()' and `std::sqrt()' and
> >><iterator> for iterator tags.]]
>
> > Adopted. I believe, that the inclusion of <iterator> is needed because
you
> > define USE_GCC and USE_COMO at the same time.
>
> Mea culpa. It wasn't `como' who complains about undefined
> iterator tags, but g++ 2.96.

Ok, I'll have to look at this again.

> `como' & g++ 3.1 are quite happy
> without <iterator>.
>
> > It looks like ublas is written in near standard C++ ;-). Thanks for your
> > effort to check ublas with Comeau's compiler and
> >
> > Best Regards
> >
> > Joerg
>
> I didn't make thorough tests yet (in particular, I didn't try banded,
> symmetric, triangular and hermitean matrices), but in due time...

Regards

Joerg