On 12/4/20 3:39 AM, Richard Biener wrote:
On Thu, Dec 3, 2020 at 10:46 PM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
On 12/3/20 10:53 AM, Jason Merrill via Gcc-patches wrote:
It looks cleaner if we can use a vec* directly as a range for the C++11
range-based 'for' loop, without needing to indirect from it, and also works
with null pointers.
The change in cp_parser_late_parsing_default_args is an example of how this
can be used to simplify many loops over vec*.
I deliberately didn't format the new overloads for etags since they are
trivial, but am open to changing that.
Tested x86_64-pc-linux-gnu. Is this OK for trunk now, or should I hold it for
stage 1?
gcc/ChangeLog:
* vec.h (begin, end): Add overloads for vec*.
* tree.c (build_constructor_from_vec): Remove *.
gcc/cp/ChangeLog:
* decl2.c (clear_consteval_vfns): Remove *.
* pt.c (do_auto_deduction): Remove *.
* parser.c (cp_parser_late_parsing_default_args): Change loop
to use range 'for'.
I'd go forward with it now, it's simple enough and simplifies the code
we end up writing...
Btw, I was disappointed about range-for seeing you cannot express
iterating from element 2 or reverse iterating. This means when we
try to adopt range-for we'll keep a messy mix of iteration style since
range-for cannot express all (or even most) iterations in our code base.
In C++20, for other ranges you use a range adaptor; to start from
element 2 you'd use https://en.cppreference.com/w/cpp/ranges/drop_view
We could add similar adaptors to GCC to use them with range-for in C++11
code, possibly drawing on the range-v3 library (which doesn't require
concepts support).
Jason
