Re: [PATCH][libstdc++-v3 parallel mode] PR 33488 improved

["Chris Jefferson" <chris at bubblescope dot net>]

On 29/09/2007, Johannes Singler <singler@ira.uka.de> wrote:
> Chris Jefferson wrote:
> > On 28/09/2007, Johannes Singler <singler@ira.uka.de> wrote:
> >> This should fix PR 33488, and a similar problem for inner_product, also
> >> adding corresponding test cases.
> >> Improved patch thanks to Sylvain Pion.
> >
> > I'm slightly worried about the idea of adding something called
> > equal_to, which is almost but not exactly std::equal_to. This seems
> > that it might later cause nasty confusion in various ways.
> >
> > I had a similar problem when I tried to remove the need for a seperate
> > implementation of each function with and without comparitor object,
>
> That a good thing to do, anyway.
>
> > the code produced and reasonably debugged is in libstdc++-v7.Have you
> > looked at how this problem was handled there, and considerduglifying
> > the non-standard equal_to, to avoid clashes?
>
> Sorry, but I cannot find any information about "libstdc++-v7". Can you
> please point me to somewhere?

It's a branch in the svn server, but for the purposes of looking at
the mappers, look in:

http://gcc.gnu.org/viewcvs/branches/libstdcxx_so_7-branch/libstdc%2B%2B-v3/include/bits/predefined_ops.h?view=markup

I can't quite remember exactly how those came about now, but I
remember we found you needed that many bits to fix all the existing
code floating about (I think mainly some strange bits of boost).

> My proposal would be to prepend "asymmetric_" to the "plus",
> "multiplies" and related functors, because they take arguments of
> different types. IMHO that's better than just uglifying them.

Normally there are issues that legal #defines can break your code, and
by the standards that's unacceptable. However, seeing as this code,
while cool, is (as I understand) not remotely strict standards
compatable, then worrying about stupid #defines possibly isn't such an
issue.

Chris