[GiNaC-list] Use of STL iterators in GiNaC
michael.goffioul at gmail.com
Thu Apr 16 14:16:44 CEST 2009
On Thu, Apr 16, 2009 at 12:10 PM, Jens Vollinga <jensv at nikhef.nl> wrote:
> Michael Goffioul schrieb:
>> I'm currently tracking down these issues by running the test
>> suite in the source package, but this might not catch all of them.
>> If you are interested, I can send a patch once I succeed to run
>> the test suite completely.
> yes, that would be interesting! I'd like to see where this happens. I don't
> have access to a VC compiler to try it myself, though.
(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:
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.
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 see no problem with dereferencing end(), and doing operations like
> end()+<integer>. In that case, end() should return a proper iterator as a
> temporary and on these the operations +,- are defined (somewhere 24.1.5 in
> the standard, I believe). But maybe there is a ++ or -- involved?
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().
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
More information about the GiNaC-list