views:

211

answers:

5

I came across this.

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Reference_Arguments#Reference_Arguments

According to the style guide, only const references are allowed as parameters. (That's what I understood)

Although, I don't seem to like that approach.

Comments?

+5  A: 

Google suggests only const references because they feel it is clearer to pass pointers when a function may modify the object. This is probably true, yet I prefer to only use pointers when null is a value that is acceptable.

To clarify, here is an example that explains the root of their argument.

Car c;
foo(c);

Whether c is modified by the function all depends on how it is declared and just looking at the call itself doesn't give much of an indication as to what could possibly happen.

void foo(Car c);  
void foo(const Car &c);  OR 
void foo(Car &c);

Now consider

Car c;
foo(&c);

Having passed the address of your object, it is easier to see (from the callers perspective) whether or not the function may be changing your object. Granted, it is not a guarantee that it is as it could be a pointer to a const object, but from a code reviewers standpoint, it is easier to detect that this object may be changed as the function is passed a pointer. When Google's suggestion is strictly enforced, an object passed via a pointer would always be mutable, while anything not passed via a pointer would be const. (either by const & or b/c of pass by value)

Whether this is better or not is debatable. I would decide how you feel and be consistent across your team.

RC
Good explanation but in the age of sophisticated IDEs passing pointers for the sake of readability seems like a dubious practice.
Duck
It's a Google practice. They have pretty strong ideas about many things... such as the use of incomplete constructors and `init` methods... I sometimes wonder if they program in C or C++
Matthieu M.
A: 

const references are great as they clearly let you know that the object will not be modified by the receiving function, plus will use the actual object that is passed in, therefore not going through the cost of creating and destroying temporary function objects.

They are useful for pretty much anything that is not a default type, as the cost of destroying and creating these objects is potentially unacceptable.

0xC0DEFACE
+4  A: 

Here are a couple of rules of thumb that can be useful when deciding between your options:

If you don't need to modify the object being passed into the function, consider whether the size of the object is less than or equal to the size of a pointer. If so, pass by value; otherwise, pass by const reference.

If you do need to modify the object being passed into the function, consider whether the parameter is optional (that is, null is a valid argument). If so, pass by pointer; otherwise, pass by non-const reference.

James McNellis
+1  A: 

it also enables that you can do

void x(const std::string& x)

x("hello");

without the const it wouldn't work.

Keith Nicholas
Why not? I don't see what you are getting at, can you expand on this?
Newton Falls
@Newton Falls:I think he means to say that "temporaries being rvalues cannot be bound to non-constant references"
Prasoon Saurav
+1  A: 

It's a preference, as I can say this is a preference:

void align_left();
// vs.
void alignLeft();

Since you want to pass arguments by non const references, then do so. I don't prefer passing pointers. The convention typically has other implications (i.e. many programmers see a pointer and think the parameter may not be required, and then have to go check the docs). So you, in convention, would typically make the parameter name indicate that it would mutate the argument.

t_result getDate(t_string& outString) const;

The name then indicates the mutation. It can be a little deceptive, if you pass by ref very rarely in your codebase, but it is ultimately 'fine' and has enough positive implications. Regarding style, a lot of it comes back to consistency. As programs really expand, (IMO) this can really help - just make sure the intent of your program is clear and the style is consistent (at least you care to read style docs before you write a huge codebase).

Justin