Thread: To what belongs the &, Card or p_card?

  1. #1
    Registered User
    Join Date
    Aug 2009
    Posts
    1

    Lightbulb To what belongs the &, Card or p_card?

    Got this back from my teacher.

    I want the printCard(int value) to recieve a card, as in:
    Code:
    void printCard(Card& p_card)
    {
    
    int value = p_card.getCardValue();
    ......
    
    }
    To what belongs the &, Card or p_card?

    any other reflections?

    Thanx

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by CppSkadad
    To what belongs the &, Card or p_card?
    The parameter type is Card&
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Depends what "belongs to" means. From a grammatical standpoint, the & binds to p_card, not Card. This can be shown by the following:

    Code:
    Card& p_card, q_card;
    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.

    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);
    //}

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by brewbuck
    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.

    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.
    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?
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by laserlight View Post
    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?
    I never declare more than one variable per line, but somebody else might come along later and try to tack on some variables to the end of an existing declaration -- I want to minimize the risk that they'll do something wrong.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by brewbuck
    I never declare more than one variable per line, but somebody else might come along later and try to tack on some variables to the end of an existing declaration -- I want to minimize the risk that they'll do something wrong.
    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.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #7
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    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.

  8. #8
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by King Mir View Post
    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.
    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:

    Code:
    class X;
    
    X a, b;
    
    X& a_ref = a, b_ref = b;
    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:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #9
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    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.

  10. #10
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Fool-proofing code is only going to go so far. So I say stick to what you feel most comfortable with.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    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.

  12. #12
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by brewbuck
    For references, the wrongness can go completely unnoticed:
    Consider this code:
    Code:
    class X;
    
    X a, b;
    
    X &a_ref = a, b_ref = b;
    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.

    Quote Originally Posted by King Mir
    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.
    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.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  13. #13
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by King Mir View Post
    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.
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Bitwise Unwanted Output
    By pobri19 in forum C++ Programming
    Replies: 4
    Last Post: 09-15-2008, 04:07 AM
  2. Vector out of range program crash.
    By Shamino in forum C++ Programming
    Replies: 11
    Last Post: 01-18-2008, 05:37 PM
  3. Segmentation Fault - aaaaaaaah!
    By yogibear in forum C Programming
    Replies: 6
    Last Post: 10-01-2007, 03:21 AM
  4. Blackjack
    By Tommo in forum C Programming
    Replies: 10
    Last Post: 06-20-2007, 08:07 PM
  5. How can I access a struct (from a header file)?
    By loxslay in forum C++ Programming
    Replies: 3
    Last Post: 10-07-2006, 01:25 PM