[GiNaC-list] Use of STL iterators in GiNaC

Jens Vollinga jensv at nikhef.nl
Thu Apr 16 15:04:23 CEST 2009


Michael Goffioul schrieb:
> (ref your patch)
> There are more issues than the ones you mention, at least with VC++.
> I'll provide a full patch in the coming days, but here are some examples:

that would be very nice!

> ncmul.cpp: ncmul::eval(int), ~line 350
> rettypes has the right capacity (due to the "reserve" call), but a
> size of 0. Then using "rettypes[0]" makes VC++ to raise an exception,
> due to internal bound checking. About this, I'm not sure what the
> standard says, but when I look at
> http://www.sgi.com/tech/stl/RandomAccessContainer.html
> the precondition is not met.

Here I agree. The code is not clean. Either we should do a proper resize 
at the beginning or use some push_back() instead of [].

> utils.h: permutation_sign(), ~line 184
> If I understand the code correctly, "other" is kept one position before
> "i". When "i" reaches "first", "other" is one position before. But when
> "first"equals std::vector::begin(), you end up decrementing begin().
> factor.cpp: modular_matrix::mul_col(), ~line 697
> When rc == (r-1), "i" gets past end().

I am not sure about the code in utils.h, but the code in factor.cpp 
looks perfectly fine to me. See below.

> I'm no C++ standard expert, but when I look at
> http://www.sgi.com/tech/stl/RandomAccessIterator.html
> my understanding of the precondition for "i += n" is that you cannot
> go after end().

It seems that the standard (I only have the draft. Hopefully there is no 
difference to the final version in the areas under consideration) and 
the SGI documentation deviate from each other. In SGI there are pre- and 
postconditions on +, -, +=, and -=. And these conditions are violated in 
the examples as you point out. But in the standard +, -, +=, -= have NO 
pre-/postconditions to them! See 24.1.5. The confusing part is, that -- 
and ++ DO have such conditions. But for the ++ operation, it is 
explicitly allowed to go past-the-end. See 24.1.4. So no problem for the 
code in factor.cpp. The code in utils.h seems to be against the 
standard, though, but I am no language lawyer and so I am maybe 
misinterpreting the conditions there. In case, this can be fixed by 
using reverse iterators.

Given the history of the STL, it is understandable that SGI deviates 
from the standard. But that Microsoft had to copy that archetype ..., 
well, here we go again ...

> To be honest, I know VC++ is by far the worst standard compliant
> compiler, but in all the situations mentioned above, I had the impression
> that ginac's code relied on undefined behaviors that happen to work fine
> on gcc/glibc.

Anyway, I think it is still good to "fix" the code if possible, so your 
patches will be appreciated.


More information about the GiNaC-list mailing list