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.

:/

Richard.

>
> jeff
>

Reply via email to