Re: [Boost-users] Boost.MultiIndex question on merge

Subject: Re: [Boost-users] Boost.MultiIndex question on merge
From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2009-04-30 04:33:34

On Thu, Apr 30, 2009 at 7:12 AM, tom fogal <tfogal_at_[hidden]> wrote:

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