[PATCH][libstdc++-v3 parallel mode] Avoid taking address of dereferenced random access iterator

[Johannes Singler]

On 03/10/2011 12:05 PM, Paolo Carlini wrote:
> 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.

Yes, I agree in principle.  You see that every time I introduce a new 
"new", this comes to my mind again ;-)
Well, the main problem is still to rethrow exceptions across threads. 
exception_ptr and rethrow_exception will help us solving this problem, I 
guess.

> 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

Would be great to make it work,

> (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...

Well, we could test std::merge with by_value_iterator, for std::sort, of 
course, you need write access to the sequence elements.  Have I maybe 
overlooked something that is similar to by_value_iterator, or is this 
not tested in general?  Well, okay, it is maybe a special requirement of 
the parallel mode that iterators should be random-accessible, but need 
not necessarily be dereference-assignable.
Such a combination of requirements is not provided in the standard AFAIK.

Johannes