[GiNaC-list] Use of STL iterators in GiNaC
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" 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
> 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
> 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