[PATCH RFC] bootstrap: Update requirement to C++11.

[Richard Biener]

On Fri, May 15, 2020 at 10:30 AM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> > Note I think what's missing is some general blurb in our coding conventions
> > as to how much of C++11 we are supposed to use in non-infrastructure parts
> > of GCC (I expect things like hash-table.h to use more C++ features than,
> > say, tree-ssa-alias.c).
>
> I guess there are two aspects to that:
>
> - Are there any specific features we should avoid using at all?
>   TBH I hope not.  Trying to police this based on C++ feature sounds
>   difficulty and might be counterproductive.
>
>   IMO it should just (continue to) be based on principles like avoiding
>   abstraction for abstraction's sake, and keeping compiler performance
>   and code size in mind.  Even tree-ssa-alias.c should be able to use
>   any C++ feature if there's a justification.
>
> - Coding conventions for when features should be used.  "auto" is an
>   obvious one.  Maybe also lambdas (which should help avoid the horrible
>   "void *" callback parameters we have all over the place now).
>
> Maybe also guidelines to actively use certain features, e.g.
>
> - use "= default" where possible
>
> - prefer range-based for loops to macros
>
> - mark "operator bool()" conversions as explicit
>
> - use "override" where applicable
>
> (all obvious I guess), etc.

I think the most important thing is that refactoring for the sake
of refactoring is bad iff it does not improve on consistency
throughout the code base.  We should really try hard to use
C++ features consistently - this makes the code base easier
to understand.

We've moved more and more to stronly-typed data structures
so I'd not like to see 'auto' everywhere - it should be still
obvious what kind of objects we're working with where they
matter.  IMHO they do not matter for example for iterators.
I don't care about the iterator type but about the type of
the object and the container.

Richard.

> Thanks,
> Richard