[PATCH][libstdc++-v3 parallel mode] Avoid taking address of dereferenced random access iterator
Paolo Carlini
paolo.carlini@oracle.com
Thu Mar 10 11:05:00 GMT 2011
Hi,
> unique_ptr is C++0x only, auto_ptr would work. But I see other heap
> allocation in that function are already unguarded so there doesn't
> seem to be much point guarding one and not the others.
I agree. Unless you have reasons to believe this case is special about
exception safety (then Jon's suggestion make sense, indeed we are
already doing something similar in basic_filebuf<>::close, just as an
example in v3) I think we should attack exception safety in a way much
wider in scope. Well, we should keep in mind that, in principle, if we
want parallel-mode to be a drop-in replacement for normal-mode,
different only in terms of performance, it should manage to appear to
the user **identical** to normal-mode about exceptions and everything
else (to be picky, for example, I suspect some proxy iterators also
don't work in an identical way with it, due to the tricks we are playing
with the comparison functors, ie, in normal-mode we have separate
versions of each algorithm because of that). Also, while we are at it
;), parallel-mode should be robust vs C++0x mode: now some code, legal
in C++0x mode, simply doesn't compile in parallel-mode (essentially we
skip testcases in the testsuite). We should improve on that, I would say
gradually, one algo at a time among those affected decide what it should
do assuming move-only types, essentially (maybe we just want the serial
version, in C++0x mode, as a first step toward fixing the compile-time
fails).
About the testcase, indeed, seems quite special. Can we figure out
something compiling and running correctly also in normal-mode, thus
actually testing something only when make check-parallel is invoked?
Would be much more inline with the way we are going with the rest of the
testsuite...
Thanks,
Paolo.
More information about the Libstdc++
mailing list