On Thu, Apr 30, 2009 at 7:12 AM, tom fogal
I find this very strange. Gcc accepted some parallelized STL implementation too in recent years, and I always questioned it. For example, 25.1.1/1 in c++98 (for_each def'n):
Effects: Applies f to the result of dereferencing every iterator in the range [first, last), starting from first and proceeding to last - 1.
How could you possibly parallelize that? It's defined to operate in series. I guess if the compiler could prove that `f' had no side effects, and there were no volatiles involved, it might be possible (is that strong enough to prove that that execution order is irrelevant? hrm..) It seems like the former would run up against solving the aliasing problem, though. What am I missing here?
(Granted, I can't recall the last time I wrote a for_each that *relied* on that execution order. Further, I could probably be convinced that requiring a particular ordering here was a specification mistake. Still, a standard is a standard.)
-tom
Tom, my example was referring to find. There you use a single value to be found in the range. That allows you to make parallel comparisons. Why should it be relevant in that context if the iterator points to a volatile value or not or is volatile itself. find-algo makes a read-only operations on container sequence. In my particular example I spoke about doing comparisons in parallel. Regards, Ovanes