Do parens cause problems when returning references?

[red floyd]

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.

 

[Roy Smith]

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.

 

[Victor Bazarov]

[..]
main()
{
int m;

(m) = 4;
}

compiles fine.

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

V

 

[Roy Smith]

[..]
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.

 

[Victor Bazarov]

[..]
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

 

[Roy Smith]

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


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.

 

[Victor Bazarov]

[..]
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

 

[red floyd]

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.