Do parens cause problems when returning references?

Discussion in 'C++' started by red floyd, May 17, 2006.

  1. red floyd

    red floyd Guest

    Given

    class C {
    int m;
    public:
    int& func() { return m; }
    // other elements redacted for brevity
    };

    Other than the fact that functions that return a handle are bad, is
    there any difference between the given C::func and

    int& C::func() { return (m); }

    I have some third party code that uses this, and the people in question
    are reluctant to change it. Comeau online doesn't complain, but I have
    doubts about whether (m) is an lvalue that's returnable.
    red floyd, May 17, 2006
    #1
    1. Advertising

  2. red floyd

    Roy Smith Guest

    In article <bkNag.18337$>,
    red floyd <> wrote:

    > Given
    >
    > class C {
    > int m;
    > public:
    > int& func() { return m; }
    > // other elements redacted for brevity
    > };
    >
    > Other than the fact that functions that return a handle are bad, is
    > there any difference between the given C::func and
    >
    > int& C::func() { return (m); }
    >
    > I have some third party code that uses this, and the people in question
    > are reluctant to change it. Comeau online doesn't complain, but I have
    > doubts about whether (m) is an lvalue that's returnable.


    The ()'s are just for grouping and are essentially no-ops in this case.
    (m) is a perfectly legal lvalue:

    main()
    {
    int m;

    (m) = 4;
    }

    compiles fine.
    Roy Smith, May 17, 2006
    #2
    1. Advertising

  3. Roy Smith wrote:
    > [..]
    > main()
    > {
    > int m;
    >
    > (m) = 4;
    > }
    >
    > compiles fine.


    It shouldn't. Your 'main' has no return value type.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, May 17, 2006
    #3
  4. red floyd

    Roy Smith Guest

    In article <e4g7up$ooq$>,
    "Victor Bazarov" <> wrote:

    > Roy Smith wrote:
    > > [..]
    > > main()
    > > {
    > > int m;
    > >
    > > (m) = 4;
    > > }
    > >
    > > compiles fine.

    >
    > It shouldn't. Your 'main' has no return value type.
    >
    > V


    You're nit-picking. It does indeed compile on my box (Mac OSX, gcc 3.3),
    and in any case, that has nothing to do with whether (m) is a legal lvalue
    or not.
    Roy Smith, May 17, 2006
    #4
  5. Roy Smith wrote:
    > In article <e4g7up$ooq$>,
    > "Victor Bazarov" <> wrote:
    >
    >> Roy Smith wrote:
    >>> [..]
    >>> main()
    >>> {
    >>> int m;
    >>>
    >>> (m) = 4;
    >>> }
    >>>
    >>> compiles fine.

    >>
    >> It shouldn't. Your 'main' has no return value type.
    >>
    >> V

    >
    > You're nit-picking.


    Yes. So? Post nit-free code and there will be no need for that.

    > It does indeed compile on my box (Mac OSX, gcc
    > 3.3), and in any case, that has nothing to do with whether (m) is a
    > legal lvalue or not.


    How do you know if you haven't disabled extensions in your compiler?
    Besides, even if it compiles on one compiler, it doesn't necessarily
    mean the code is fine. Portability is the name of the game here,
    and one compiler cannot be a true measure of that.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, May 17, 2006
    #5
  6. red floyd

    Roy Smith Guest

    In article <e4g8t8$qap$>,
    "Victor Bazarov" <> wrote:

    > Yes. So? Post nit-free code and there will be no need for that.
    >
    > > It does indeed compile on my box (Mac OSX, gcc
    > > 3.3), and in any case, that has nothing to do with whether (m) is a
    > > legal lvalue or not.

    >
    > How do you know if you haven't disabled extensions in your compiler?
    > Besides, even if it compiles on one compiler, it doesn't necessarily
    > mean the code is fine. Portability is the name of the game here,
    > and one compiler cannot be a true measure of that.


    Sigh. I was just using that code as an example. I know (m) is an lvalue
    from experience, but since you're being insistent, I went and looked it up.

    Section 5.1, paragraph 5 of INTERNATIONAL STANDARD ISO/IEC 14882 First
    edition 1998-09-01 Programming languages C++, says:

    "A parenthesized expression is a primary expression whose type and value
    are identical to those of the enclosed expression. The presence of
    parentheses does not affect whether the expression is an lvalue. The
    parenthesized expression can be used in exactly the same contexts as those
    where the enclosed expression can be used, and with the same meaning,
    except as otherwise indicated."

    Section 3.6.1, paragraph 2 of that same document does indeed say that main,
    "shall have a return type of type int", so yes, the code I posted is not
    correct in that respect, but the primary point of my post was to illustrate
    that (m) is indeed an lvalue.
    Roy Smith, May 18, 2006
    #6
  7. Roy Smith wrote:
    > [..]
    > Sigh. I was just using that code as an example. I know (m) is an
    > lvalue from experience, but since you're being insistent, I went and
    > looked it up.
    >
    > Section 5.1, paragraph 5 [..]


    Roy,

    That's a totally different way of presenting your valuable information!

    I am absolutely sure that "red floyd" will be much happier with this in
    his arsenal than something like "yeah, don' worry 'boutit", especially
    if somebody asks, "how do you know it's OK to drop them parens?"

    Best!

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, May 18, 2006
    #7
  8. red floyd

    red floyd Guest

    Roy Smith wrote:

    > Section 5.1, paragraph 5 of INTERNATIONAL STANDARD ISO/IEC 14882 First
    > edition 1998-09-01 Programming languages C++, says:
    >
    > "A parenthesized expression is a primary expression whose type and value
    > are identical to those of the enclosed expression. The presence of
    > parentheses does not affect whether the expression is an lvalue. The
    > parenthesized expression can be used in exactly the same contexts as those
    > where the enclosed expression can be used, and with the same meaning,
    > except as otherwise indicated."
    >

    Thank you. I was looking for 5.1/5.
    red floyd, May 18, 2006
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Stephen Ferg

    How to avoid "f.close" (no parens) bug?

    Stephen Ferg, Feb 11, 2004, in forum: Python
    Replies:
    12
    Views:
    483
    Nick Craig-Wood
    Feb 13, 2004
  2. Batista, Facundo

    RE: How to avoid "f.close" (no parens) bug?

    Batista, Facundo, Feb 11, 2004, in forum: Python
    Replies:
    2
    Views:
    240
    Neil Hodgson
    Feb 11, 2004
  3. Batista, Facundo

    RE: How to avoid "f.close" (no parens) bug?

    Batista, Facundo, Feb 11, 2004, in forum: Python
    Replies:
    2
    Views:
    272
    Peter Hansen
    Feb 11, 2004
  4. Michael Chermside

    How to avoid "f.close" (no parens) bug?

    Michael Chermside, Feb 13, 2004, in forum: Python
    Replies:
    0
    Views:
    249
    Michael Chermside
    Feb 13, 2004
  5. Replies:
    8
    Views:
    605
    William Park
    Jul 4, 2005
Loading...

Share This Page