Hi, 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. Regards, Jens