Boost logo

Boost Users :

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



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net