On Fri, May 15, 2020 at 5:58 AM Richard Sandiford <richard.sandif...@arm.com>
wrote:
> Richard Biener <richard.guent...@gmail.com> writes:
> > On Fri, May 15, 2020 at 10:30 AM Richard Sandiford
> > <richard.sandif...@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.
>
> Agreed. One of the reasons I'm keen to have something in the
> coding standards is that things became less consistent after
> the C->C++ switch.
>
> Maybe we should reconsider some of the existing coding standards too.
> E.g.:
>
> Define all members outside the class definition.
> That is, there are no function bodies or member initializers
> inside the class definition.
>
> isn't widely followed. That's a bit of a tangent though.
> (FTR, I've no attachment to the current conventions and didn't
> contribute anything to them. More consistency would be good though.)
>
> > 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.
>
> Also agreed. :-) How about this as a starting point:
>
> ---------------------------------------------------------------
> Use auto for:
>
> - the result of casts or other expressions that give the type
> explicitly. E.g.:
>
> if (auto *table = dyn_cast <rtx_jump_table_data *> (insn))
>
> instead of:
>
> if (rtx_jump_table_data *table = dyn_cast <rtx_jump_table_data *>
> (insn))
>
> - iterator types. E.g.:
>
> auto it = foo.begin ();
>
> instead of:
>
> foo_type::iterator it = foo.begin ();
>
> - expressions that provide an alternative view of something,
> when the expression is bound to a read-only temporary. E.g.:
>
> auto val1 = wi::to_wide (...);
> auto val2 = wi::uhwi (12, 16);
>
> instead of:
>
> wide_int val1 = wi::to_wide (...);
> wide_int val2 = wi::uhwi (12, 16);
>
> (Using "wide_int" is less efficient than using the natural type of
> the expression.)
>
> - the type of a lambda expression. E.g.:
>
> auto f = [] (int x) { return x + 1; };
>
> Do not use auto otherwise.
>
We probably also want to use auto for local variables in templates where
the initializer is type-dependent.
Jason
