- User Since
- Nov 22 2018, 4:49 AM (34 w, 1 d)
Mon, Jul 8
Thu, Jun 27
I don't mind. All I care is that this stuff stays out of the main include directory.
Fri, Jun 21
thanks for the alternative proposal.
Jun 13 2019
- The test was improved.
- Minor changes in PSTL code. It needs for possibility of coverage that case in "negative test scenario".
Jun 6 2019
+ fix filename in a file header
Added a negative test for exclusive_scan algorithm. It checks non-participation the algo declare in overload resolution.
Jun 4 2019
Add uglification for "merge_task" and Rebased to the HEAD
Jun 3 2019
May 31 2019
Apr 26 2019
+ "internal::" for "brick_move"
Rebased of the HEAD of the master
Apr 24 2019
What do you think about my last proposal regarding
Apr 23 2019
Apr 22 2019
But let's avoid any name/path that suggests these headers are part of the public interface of the library, because they are not
Apr 18 2019
If the problem with passing test inplace_merge.pass.cpp" is actual, I'll investigate and fix it by proposed new patch over the top your changes.
I don't think the pstl should include headers that are useless to all but one specific shipping vehicle of the PSTL (the standalone version)
I have an issue regarding the dummy stdlib headers.
Proposed location is valid only for the test. (/test/support/stdlib)
Apr 15 2019
In that case, may we "reserve" MINOR version to differ PSTL code version?
// The version is XYYZ, where X is major, YY is minor, and Z is patch (i.e. X.YY.Z)
Apr 12 2019
Continuing the discussion - the code snippet of the test engine - pay your attention to using namespace __pstl::execution
we should have a way to customize the namespace in which pstl injects the algorithms
Apr 11 2019
Eventually, I tend to that keeping "cout" code is redundant , just "return 0" is enough.
We will try to re-config our test system to accept just returning zero;
I don't see any "bookmarks" (technical, and others) on scheme versioning on our side.
So, I've no objections against the proposed approach.
I understand that given pstl code is becoming a part of C++ standard library and , of course should be std::execution::unsequenced_policy and so on..
I have no objections in general..
But let add the line
Apr 10 2019
Apr 8 2019
I think we all agreed that this was worth implementing
Apr 4 2019
Of course. I will configure "ninja" for running the upstream test.
Apr 3 2019
..no matching function for call to 'equal' return std::equal(first1, last1, first2, last2, __p);
+ compilation fixes (lost "__").
The lost "__" has been returned.
Rebased on top of latest master (+ uglification)
Mar 28 2019
Yes,... I doubted that is relevant to LLVM release.. and so as the some other macros form pstl_config.h
But as far as pstl_config.h is, PSTL_VERSION may be useful, at least to differ major changes, I guess...
Mar 27 2019
- Usage of std::equal with "4 iterators" (due to it is available in C++ standard library since C++14)
- Clang formatted
Mar 26 2019
At least, it "extends" signature of functions of a back-end that helps (now) to support several back-ends in the same time (by overloading).
a significant gain in readability
Mar 25 2019
Mar 22 2019
Mar 13 2019
Mar 5 2019
pstl_config.h is not required
Feb 19 2019
Jan 10 2019
Jan 9 2019
Yes, a captured __comp instance is redundant in the all cases here due to it is passed via argument's list explicitly.