Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: formalize non-const reference usage in C++ style guide #23155

Closed
Closed
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 34 additions & 0 deletions CPP_STYLE_GUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,7 @@
* [Memory allocation](#memory-allocation)
* [Use `nullptr` instead of `NULL` or `0`](#use-nullptr-instead-of-null-or-0)
* [Ownership and Smart Pointers](#ownership-and-smart-pointers)
* [Avoid non-const references](#avoid-non-const-references)
* [Others](#others)
* [Type casting](#type-casting)
* [Do not include `*.h` if `*-inl.h` has already been included](#do-not-include-h-if--inlh-has-already-been-included)
Expand Down Expand Up @@ -200,6 +201,39 @@ void FooConsumer(std::unique_ptr<Foo> ptr);

Never use `std::auto_ptr`. Instead, use `std::unique_ptr`.

### Avoid non-const references

Using non-const references often obscures which values are changed by an
joyeecheung marked this conversation as resolved.
Show resolved Hide resolved
refack marked this conversation as resolved.
Show resolved Hide resolved
refack marked this conversation as resolved.
Show resolved Hide resolved
assignment. A pointer is almost always a better choice.

```c++
class ExampleClass {
public:
explicit ExampleClass(int* int_ptr) : pointer_to_integer_(int_ptr) {}

void SomeMethod(const std::string& input_param,
std::string* in_out_param); // Pointer instead of reference

const std::string& get_foo() const { return foo_string_; }
void set_foo(const std::string& new_value) { foo_string_ = new_value; }

void ReplaceCharacterInFoo(char from, char to) {
// A non-const reference is okay here, because the method name already tells
// users that this modifies 'foo_string_' -- if that is not the case,
// it can still be better to use an indexed for loop, or leave appropriate
// comments.
for (char& character : foo_string_) {
if (character == from)
character = to;
}
}

private:
std::string foo_string_;
int* pointer_to_integer_; // Pointer instead of reference.
Copy link
Member

@joyeecheung joyeecheung Oct 1, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally in cases like this I'd prefer to use a normal int here and return references because it's more memory-efficient (and if this is storing a pointer to mutate it the ownership seems to be pretty hard to figure out..)...maybe a member object with a made-up class here would be clearer? Or a unique_ptr since that's what we generally try to refactor to? (Or a shared_ptr but we don't seem to use it much in our codebase and try to restructure the ownership towards a unique_ptr)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 … How about e9f8406?

};
```

## Others

### Type casting
Expand Down