Re: [boost] Re: uBLAS: problem with sparse_vector

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-27 22:29:33

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. 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. 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... ;-)

-Dave