|
|
|
|
|
by bminor13
2269 days ago
|
|
> 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) |
|
But the moment you've called
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.