[libcxx-commits] [PATCH] D60480: [WIP] integration of pstl into libc++

Tue Apr 9 22:17:57 PDT 2019

rodgert added a comment.

In D60480#1460300 <https://reviews.llvm.org/D60480#1460300>, @ldionne wrote:

> The purpose of this review is to expose how I plan to integrate the parallel STL into libc++, and to discuss some changes that are desirable in pstl for this to be possible. This is a work in progress, obviously, and it's meant as a concrete support for having discussions.
>
> Concrete changes I think we need to make in pstl:
>
> - Rename all the files to double underscores.

This isn't a libstdc++ convention, but I'm not opposed.

> - Move everything that's meant to be included directly by standard library implementations out of `internal/`, since that doesn't make sense. It's not internal, it's the API of PSTL (which is meant to be consumed by standard libraries).

I would like to maintain a clear separation between the bits that implement PSTL and the glue bits that tie into a given library. Currently everything in 'internal/' goes to libstdc++v3/include/pstl when I integrate with libstdc++v3. I don't want to be left guessing what those files are, I want them to move as a cohesive unit into the library's implementation detail. We can name whatever we want.

> - We could provide the glue definitions and declarations as `.ipp` files that are meant to be included by standard libraries as-is. The Standard library could then define stuff like the namespace in which those declarations are injected, etc.

I would be interested in exploring this, subject to the caveat that whole of what's currently in 'internal' is an obvious package of related implementation detail that I can poke into libstdc++ as a unit.

> I also suggest:
> 
> - Removing the `<algorithm>` & friends headers from PSTL itself. Those don't belong there, they belong with the standard library.
> 
>   WDYT @rodgert ?

If we remove them, then we sort of lose the ability to test pstl outside of standard library, no? I'm not going to be testing or packaging libc++ most likely, but I am going to be contributing changes here and running tests within the context of libstdc++. Having the ability to test changes to the library independent of any integration with another standard library is still useful for me.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60480/new/

https://reviews.llvm.org/D60480