Boost logo

Boost :

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-06-28 00:37:09


----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, June 28, 2002 5:29 AM
Subject: Re: [boost] Re: uBLAS: problem with sparse_vector

> From: "Michael Stevens" <support-1_at_[hidden]>
>
> > >The element v(1) is 0 instead of 42. The bug comes from the fact that
> > v(1) is
> > >evaluated before v(0) = 42. The bug is not present with the Intel
> > compiler on
> > >the same platform.
> >
> > This bug seems to be GCC exclusive, it works fine with MSVC7. I can also
> > confirm that GCC3.1 shows the same behaviour.
> > I suspect this to be a GCC bug and nothing to do with uBLAS. Looking at
> > the execution path confirms this. All uBLAS 'v(x)' does is return a
> > reference to a double
>
> Something doesn't jibe here. If v(x) really *just* returns a double&, it
> doesn't matter whether v(0) is evaluated before or after v(1) = 42.
>
> On the other hand, if v(0) inserts an element in sparse storage, then it
> almost certainly matters. And the order of evaluation of v(0) and v(1) is
> unspecified according to the standard, so this sounds like a library bug
to
> me.

sparse_vector::operator() has this side effect, indeed. So it seems I've to
confirm this to be a ublas bug ;-(

> The "right" way to do sparse container indexing, AFAIK, has always been
> to use proxies. Thus, v(0) and v(1) would return proxies that do not
insert
> anything until assigned to.

I'll try to fix.

> Anyway, it would be a shame if a sparse vector
> becomes dense just because I decide to examine all the (possibly
> not-stored) elements.
>
> > >Note: there is the same problem with Loki::AssocVector.
> >
> > This seems to confirm it is a compiler and not a library problem. Anyone
> > out there know if GCC generaly has problems with returned references?
>
> Heh, I suppose two separate library authors are incapable of making the
> same mistake... ;-)

Regards

Joerg


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk