Hacker News Reader

Comment by bminor13 | Hacker News Reader

I have some nitpicks with the advice given in the table:

> Q1: Yes Q2: - Q3: No Argument: `Widget& widget`

...or `Widget* widget`, which has drawbacks but makes it more clear at the callsite that the argument passed may be modified. The Google style guide prefers this for this reason: https://google.github.io/styleguide/cppguide.html#Reference_...

> Q1: No Q2: No Q3: - Argument: `Widget widget`

Q2 IMO should have an addendum to read "Is it expensive to copy a Widget and if not, will it always be cheap" because there is nothing to stop someone from adding to Widget until it crosses the threshold of "expensive", at which point someone needs to go through and update all the callsites to pass by const ref. Widget's copy cost really needs to be part of its API contract before pass-by-value can be allowed.

View on HN

google's rationale is good but not iron-clad.

in ardour, we use the convention that if a null value is allowed, pass a pointer; if a null value is not allowed, pass a ref.

the idea that Widget& implies something different about the likelihood of modification compared with Widget* is quite foreign to me. this is precisely what Widget const & is for.

> the idea that Widget& implies something different about the likelihood of modification compared with Widget* is quite foreign to me. this is precisely what Widget const & is for.

The issue is not ambiguity in the declaration, but rather the callsite: it's rarely possible to tell if a parameter is passed as a value, ref, or const ref at a particular callsite without consulting the function declaration. Oftentimes, one reads code without comparing each function call to its declaration, so it's easy to miss instances where objects are passed around by mutable ref rather than the more common const ref.

Using a pointer for the mutable cases resolves this ambiguity by forcing different syntax to be used at the callsite, which reminds:

* code authors that the parameter they're passing can be modified by the function call (they should think carefully about whether this is desired)

* code readers that a function call is potentially modifying its parameter (which can aid in debugging)

That works if the call stack is only ever shallow (specifically, the owner is always the caller).

But the moment you've called

   hello_i_accept_pointers (&myvar)

you're now inside a callstack where the variable is a pointer, and there's no syntax to indicate that you're passing a pointer to the next callee.

That's true; inside `hello_i_accept_pointers` there's no syntax at callsites to indicate that a mutable pointer is being passed. However, the variable being passed is of pointer type, which is readily apparent from the context of the function - the pointer parameter is declared in the same file, likely only lines above the callsite in question. This is still better than having to find the declaration of the called function, which is probably in a different file altogether.

what are these files that you speak of ? :))

seriously, even with trusty old emacs and ag(1), the declaration of the called function is a fraction of a second away, no matter where it lives.

But having it obvious at the call site means I don't even have to do that, dozens of times per day, every day.

It's something that's not easy to realize how useful it is until you actually do it. When working in a large codebase that consistently follows those rules it just makes code reading a breeze, it severely reduces the number of "context switches".

Obviously it's not the only way it can be done but it is a way and the benefits are significant.

> there is nothing to stop someone from adding to Widget until it crosses the threshold of "expensive"

Generally, things that are passed by value are de-facto “frozen” and will not have new members added to them, as they’d no longer be “zero cost”. For example, std:string::iterator is “logically” a char * and this will likely never change.

Reply on news.ycombinator.com