[PATCH 2/3] libstdc++: Implement C++20 constrained algorithms

[Jonathan Wakely]

On 05/02/20 19:39 +0100, François Dumont wrote:
>Hi
>
>    Is it me or the patch isn't an attachment ? It is far more 
>convenient to provide something easy to extract and apply locally.
>
>On 2/4/20 3:07 AM, Patrick Palka wrote:
>>This patch implements the C++20 ranges overloads for the algorithms in
>>[algorithms].  Most of the algorithms were reimplemented, with each of their
>>implementations very closely following the existing implementation in
>>bits/stl_algo.h and bits/stl_algobase.h.  The reason for reimplementing most of
>>the algorithms instead of forwarding to their STL-style overload is because
>>forwarding cannot be conformantly and efficiently performed for algorithms that
>>operate on non-random-access iterators.  But algorithms that operate on random
>>access iterators can safely and efficiently be forwarded to the STL-style
>>implementation, and this patch does so for push_heap, pop_heap, make_heap,
>>sort_heap, sort, stable_sort, nth_element, inplace_merge and stable_partition.
>>
>>What's missing from this patch is debug-iterator
>
>Always the 5th wheel of the car like we say in French :-)
>
>I'll be looking at this point once I manage to apply the patch.
>
>>  and container specializations
>>that are present for some of the STL-style algorithms that need to be ported
>>over to the ranges algos.  I marked them missing at TODO comments.  There are
>>also some other minor outstanding TODOs.
>>
>>The code that could use the most thorough review is ranges::__copy_or_move,
>>ranges::__copy_or_move_backward, ranges::__equal and
>>ranges::__lexicographical_compare.  In the tests, I tried to test the interface
>>of each new overload, as well as the correctness of the new implementation.
>>
>>diff --git a/libstdc++-v3/include/bits/ranges_algo.h b/libstdc++-v3/include/bits/ranges_algo.h
>>new file mode 100644
>>index 00000000000..2e177ce7f7a
>>--- /dev/null
>>+++ b/libstdc++-v3/include/bits/ranges_algo.h
>>@@ -0,0 +1,3640 @@
>>+// Core algorithmic facilities -*- C++ -*-
>>+
>>+// Copyright (C) 2019-2020 Free Software Foundation, Inc.
>
>Copyright for new files is wrong, should be only 2020. I know it is 
>painful to maintain that when you work on patch on several years.

I assume Patrick kept the 2019 date because his patch started from a
file I sent him with a few of the algos, and that was dated 2019.

I can't remember what the actual rule is for new files that contain
old code. The copyright on some of the new file *is* from 2019, even
if it wasn't added to the GCC repo yet.

New files containing new code should definitely only have the new date
(usually when I point out wrong dates in patch review it's because
somebody's just copied the comment header from an old testcase and so
the old dates are wrong).

I only wrote that code in December 2019 though, so it doesn't make a
lot of difference either way, 2020 is fine.