nine.fierce.ball...@gmail.com writes:
> Consider this function from lily/tie-formatting-problem.cc:
>
> void
> Tie_formatting_problem::score_ties (Ties_configuration *ties) const
> {
> if (ties->scored_)
> return;
>
> score_ties_configuration (ties);
> score_ties_aptitude (ties);
> ties->scored_ = true;
> }
>
> What is the benefit to using pointers here? I expect a supporter of
> Google's style to answer that it's true that there is no benefit here,
> but there is a benefit somewhere up the call chain. That's here:
>
> variant.reset_score ();
> score_ties (&variant);
>
> if (variant.score () < best.score ())
> {
> best = variant;
> }
>
> That is difficult to misunderstand with or without the ampersand.
Well, it is not clear whether this is just an input parameter or in-out,
and how efficiently it is being passed. The efficiency arguably is only
the business of the called site, not every caller, and it is still not
possible to see the difference between Ties_configuration *ties and
Ties_configuration const *ties at the call site.
> The non-null information that references communicate is more useful
> than what the ampersand provides here.
Well, if we really wanted to signify the parameter as being used in-out,
we could do
score_ties (*&variant);
even with a reference parameter. Of course this does not "really" give
an indication about this being in-out, but neither does &variant.
If it's important, one could use
score_ties (/*in-out*/ variant);
> https://codereview.appspot.com/577440044/
I think this convention is supposed to make it easy to see which
parameters may be output parameters. But that makes a whole lot more
sense as a conventions for types like int (where passing by pointer
would be unusual) rather than class types which you basically always
want to pass by using a memory reference, whether in the form of a C++
reference or a pointer, regardless of whether they are input-only or
in-out or output-only.
--
David Kastrup
