Got this back from my teacher.
I want the printCard(int value) to recieve a card, as in:
To what belongs the &, Card or p_card?Code:void printCard(Card& p_card) { int value = p_card.getCardValue(); ...... }
any other reflections?
Thanx
Got this back from my teacher.
I want the printCard(int value) to recieve a card, as in:
To what belongs the &, Card or p_card?Code:void printCard(Card& p_card) { int value = p_card.getCardValue(); ...... }
any other reflections?
Thanx
The parameter type is Card&Originally Posted by CppSkadad
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Depends what "belongs to" means. From a grammatical standpoint, the & binds to p_card, not Card. This can be shown by the following:
This declares p_card to be a reference to a Card, and q_card to be a Card (not a reference). This is perhaps not what you would expect. If you intended to declare two references, you would have to write:Code:Card& p_card, q_card;
This is why I put the & next to the variable instead of the type. It reminds me (and others) that the binding is to the right and helps avoid this mistake.Code:Card &p_card, &q_card;
In your case, of a function argument list, you cannot have declarations like the above, but I still write the & to the right for consistency with the other case.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Alternatively, you can keep the & next to the type name, and never declare more than one variable per declaration, except maybe when the variables are not of reference (or pointer) type. Stroustrup discusses this in Is ``int* p;'' right or is ``int *p;'' right?Originally Posted by brewbuck
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Unfortunately, I think that the only way to properly minimise that risk is to change the grammar of the language. A way to minimise the risk of a "tacking on" is to highlight it in a code review, whether or not it is "obviously" correct.Originally Posted by brewbuck
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Really though, it's a non issue. Even if somebody mistakes a declaration like this for declaring 2 pointers, the error will quickly be noticed if that person treats it like a pointer and tries to compile.
By the way, brewbuck's examples are not valid, since references must be initialized.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
I think you highlighted precisely the danger I am talking about. For pointers, you are correct and a compile-time error will usually result (I say usually, because some stupid cast somewhere might make the code syntactically ok). For references, the wrongness can go completely unnoticed:
This is VALID CODE, but it is not what was intended. b_ref obtains a COPY of b instead of being a reference to b. Oops.Code:class X; X a, b; X& a_ref = a, b_ref = b;
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Good point.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
That's true, but the kind of people who ask questions like this don't yet have any strong habits about it. So we should tell them the best way to do it, even if we don't follow it.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Consider this code:Originally Posted by brewbuck
Frankly, I think the wrongness can still go completely unnoticed. A static analysis tool that can spot such potential errors can spot it either way, and a review policy that always highlights such declarations for change can also spot such potential errors either way.Code:class X; X a, b; X &a_ref = a, b_ref = b;
But what is the best way of doing it? If you instruct people to stick to declaring one variable per line, then in theory brewbuck's worry about someone making a mistake when "tacking on" will disappear since "tacking on" won't happen.Originally Posted by King Mir
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Best is subjective.
I'm more concerned about people who get confused about different styles of declarations. Say they are using T &v and then see T& v. They get confused.
So rather than using a "best practice," I find it better that they learn what it actually means, select a style and stick with it.