On Tue, Jul 14, 2015 at 04:31:16PM +0200, Martin Liška wrote:
> On 06/25/2015 08:28 PM, Richard Sandiford wrote:
> > Sorry in advance for inviting a bikeshed discussion, but while making
> > the hashing changes that I just committed, I noticed that the C++ification
> > has been done in a variety of different styles. I ended up having to follow
> > the "do what the surrounding code does" principle that some code bases have,
> > but to me that's always seemed like an admission of failure. One of the
> > strengths of the GCC code base was always that it was written in a very
> > consistent style. Regardless of what you think of that style (I personally
> > like it, but I know others don't at all), it was always easy to work on
> > a new area of the compiler without having to learn how the surrounding code
> > preferred to format things. It would be a shame if we lost that in the
> > rush to make everything "more C++".
> >
> > The three main inconsistencies I saw were:
> >
> > (1) Should inline member functions be implemented inside the class or
> > outside
> > the class? If inside, should they be formatted like this:
> >
> > void
> > foo (args...)
> > {
> > ...;
> > }
> >
> > or like this:
> >
> > void
> > foo (args...)
> > {
> > ...;
> > }
> >
> > (both have been used).
> >
> > The coding standard is pretty clear about this one:
> >
> > Define all members outside the class definition. That is, there
> > are no function bodies or member initializers inside the class
> > definition.
> >
> > But in-class definitions have become very common. Do we want
> > to revisit this? Or do we just need more awareness of what the
> > rule is supposed to be?
> >
> > [Personally I like the rule. The danger with in-class definitions
> > is that it becomes very hard to see the interface at a glance.
> > It obviously makes things more verbose though.]
It seems pretty clear to me that there is a trade off here, so imho its
better to trust reviewers and authors to make good choices than to
proscripe a rule for making choices.
> > (2) Is there supposed to be a space before a template parameter list?
> > I.e. is it:
> >
> > foo<bar>
> >
> > or:
> >
> > foo <bar>
> >
> > ? Both are widely used.
> >
> > The current coding conventions don't say explicitly, but all the
> > examples use the second style. It's also more in keeping with
> > convention for function parameters. On the other hand, it could
> > be argued that the space in:
> >
> > foo <bar, frob>::thing
> >
> > makes the binding confusing and looks silly compared to:
> >
> > foo<bar, frob>::thing
> >
> > But there again, the second one might look like two unrelated
> > blobs at first glance.
personally I find foo <...> strange, but *shrug*
> >
> > (3) Do we allow non-const references to be passed and returned by
> > non-operator functions? Some review comments have pushed back
> > on that, but some uses have crept in.
> >
> > [IMO non-const references are too easy to misread as normal
> > parameters.]
I personally would strongly discourage them, but I'm willing to believe
there are places they are the right choice.
> >
> > In all three cases, whether the answer is A or B is less important
> > than whether the answer is the same across the code base.
I'm in favor of consistancy so long as the consistancy doesn't make
things substancially worse (horribly worded, but the point is its a
trade off ;))
> >
> > If this message does generate any discussion, I'm happy to write up
> > the result in the coding conventions and try to make the code base
> > consistent with it.
> >
> > Thanks,
> > Richard
> >
>
> Hello.
>
> I've got one related question about a class methods. Is there any rule that
> says
> comments related to a function method should be just in declaration or both
> declaration
> and definition? I would welcome to write comments just once :)
Personally I prefer only in the declaration, but existing practice seems
to be all over the board. coppying comments around seems obviously bad
though.
Trev
>
> Thanks,
> Martin
