On 07/16/2018 04:19 AM, Richard Sandiford wrote:
Aldy Hernandez <al...@redhat.com> writes:
On Thu, Jul 12, 2018 at 1:41 PM Jonathan Wakely <jwakely....@gmail.com> wrote:
On Thu, 12 Jul 2018 at 11:41, Richard Sandiford wrote:
+Only use non-constant references in the following situations:
+</p>
+
+<ul>
+<li>when they are necessary to conform to a standard interface, such as
+the first argument to a non-member <code>operator+=</code></li>
And the return value of such operators (which also applies to member
operators, which is the more conventional way to write compound
assignment operators).
+<li>in a return value, when providing access to something that is known
+to be nonnull</li>
+</ul>
+
+<p>
+In other situations the convention is to use pointers instead.
+</p>
+
+<blockquote>
+<pre><code>HOST_WIDE_INT do_arith (..., bool *overflow); // OK
+HOST_WIDE_INT do_arith (..., bool &overflow); // Please avoid
I understand the objection to using references for out parameters (an
alternative to pointers is to return a struct with the wide int result
and the overflow flag), but ...
Putting everything in a new struct is just going through more hoops to
avoid a common language idiom that everyone in C++ is used to.
+int *elt = &array[i]; // OK
+int &elt = array[i]; // Please avoid
... this seems unnecessary. If the function is so long that the fact
elt is a reference can easily get lost, the problem is the length of
the function, not the use of a reference.
Agreed.
Richard (Sandiford), this really looks like going out of your way to
enforce a personal style issue across the entire code base. It's sad
that we try to come up with new ways to make it even harder for new
developers to contribute to GCC.
It's not enforcing a personal style issue so much as trying to stop
the source base from becoming even more inconsistent, admittedly in one
particular area only.
Before the switch to C++, GCC was one of the most consistent source
bases I'd seen (more so even than LLVM IMO, having worked on both).
It's clearly less so now. The problem isn't just legacy C-era code vs.
new C++ code, but different styles being used for the C++ code.
I certainly appreciate your concern, and the time you have taken to
amend the guidelines. However, perhaps we should get consensus here, as
this is an issue that affects us all.
(It was interesting that Martin complained earlier in the thread about
how inconsistent GCC was. I imagine that's the impression that new
developers would have now, rather than being glad that they can use
references to return things.)
In the case of pointers vs. reference parameters for returning values,
we have a clear precendent from the C days and very few existing C++
functions that deviate from it. So if we were going to pick one,
it seemed obvious which we should pick. Perhaps there's an argument
that eventually everything will move over to the new style due to
natural churn, but I think another half-transition is far more likely.
Heh. I would definitely prefer moving to the new style ;-).
But weight of opinion definitely seems to be against adding that rule
to the standards, so I'll drop the patch.
Again, I have a preference for non constant references if it makes the
code easier to read, but I don't feel so strongly as to fight about it,
especially if there is consensus going the other way.
I welcome more discussion on this, and will gladly accept what the
majority agrees on.
Aldy
