Is there a difference between these two statements inside a function?
bool returnValue = true;
// Code that does something
return(returnValue);
and this?
bool returnValue = true;
// Code
return returnValue;
The former has parentheses around returnValue.
C++14 adds a fringe case where parentheses around a return value may alter the semantics. This code snippet shows two functions being declared. The only difference is parentheses around the return value.
int var1 = 42;
decltype(auto) func1() { return var1; } // return type is int, same as decltype(var1)
decltype(auto) func1() { return(var1); } // return type is int&, same as decltype((var1))
In the first func1 returns an int and in the second one func1 returns an int& . The difference in semantics is directly related to the surrounding parentheses.
The auto specifier in its latest form was introduced in C++11. In the C++ Language Spec it is described as:
Specifies that the type of the variable that is being declared will be automatically deduced from its initializer. For functions, specifies that the return type is a trailing return type or will be deduced from its return statements (since C++14)
As well C++11 introduced the decltype specifier which is described in the C++ Language Spec:
Inspects the declared type of an entity or queries the return type of an expression.
[snip]
If the argument is either the unparenthesised name of an object/function, or is a member access expression (object.member or pointer->member), then the decltype specifies the declared type of the entity specified by this expression.
If the argument is any other expression of type T, then
a) if the value category of expression is xvalue, then the decltype specifies T&&
b) if the value category of expression is lvalue, then the decltype specifies T&
c) otherwise, decltype specifies T
[snip]
Note that if the name of an object is parenthesised, it becomes an lvalue expression, thus decltype(arg) and decltype((arg)) are often different types.
In C++14 the ability to use decltype(auto) was allowed for function return types. The original examples are where the semantic difference with parentheses comes into play. Revisiting the original examples:
int var1 = 42;
decltype(auto) func1() { return var1; } // return type is int, same as decltype(var1)
decltype(auto) func1() { return(var1); } // return type is int&, same as decltype((var1))
decltype(auto) allows the trailing return type in the function to be deduced from the entity/expression on the return statement. In the first version return var1; is effectively the same as returning the type decltype(var1) (an int return type by rule 1 above) and in the second case return (var1); it's effectively the same as decltype((var1)) (an int & return type by rule 2b).
The parentheses make the return type int& instead of int, thus a change in semantics. Moral of the story - "Not all parentheses on a return type are created equal"
return (x); is equivalent to return &x;, nor should it be possible for it to result in a return of the value of x but with the type reference to x. –
Jacey auto quite often. Do our semantics never change as long as we stay away from decltype? I am afraid of unexpected behavior when we move on to the next compiler version that incorporates the next Visual Studio. –
Woodworker There is no difference.
One reason to use parenthesis would be if you wanted to evaluate an expression before returning but in your example, there would be no reason. See:
Parenthesis surrounding return values
for further discussion.
return m * x + c and return (m * x + c) or return ( (m * x) + c ) or etc. - and it doesn't look any better or more intuitive either, if you ask me. –
Possie AFAIK, nothing is different.
In C++, expressions can have the form: expr or (expr). So, the latter is an expression with more typing. For further reading about this, refer to a grammar (look for "expression").
The parenthesis on the upper example are superfluous; they are effectively ignored.
It would be the same as something like...
int x = (5);
The parenthesis here are ignored as well.
throw, sizeof, case, etc. also don't require parentheses. if, for etc. require them solely to prevent ambiguity with the following expression/block (simplest example to show this: if (x) +1; is valid C++, and would be ambiguous without parenthese; that's why all langauges that don't have parentheses around if expressions require some token afterwards to disambiguate, e.g. :, then, { etc.). Does this clear it up? –
Omniscience if, in that f(x) + 1 is ambiguous without parentheses. Sure, it's arbitrary that we don't use e.g. Haskell syntax, and you're wrong in fact: C++ syntax does not mirror what mathematicians do, because mathematics generally does not use parentheses around the argument of function application ("f x" is conventional notation for function application in mathematics). So yes, in the end the choice is arbitrary. But it is not arbitrary that return (and throw and sizeof, etc.) is different from if etc. –
Omniscience if etc. but not for return etc. –
Omniscience No difference!!
People use parenthesis if there's a complex expression involved.
BTW return is a statement not a function.
Nope there's no difference between the two, although you can include parenthesis if it makes the expression easy to read and clear.
return is a greedy operator and that return m * x + c might return m and discard the rest, or what? –
Possie You're abusively slowing down the compiler!
The presence of parenthesis not only slow down the preprocessing phase, but they generate a more complicated Abstract Syntax Tree too: more memory, more computation.
From a semantic point of view ? They are exactly identical. Whether there are parenthesis or not the return statement will fully evaluate the expression before returning it.
if, for, or while, and they're not missed. Parentheses around functions arguments are more difficult to get rid of: should f 3 + 4 be parsed as f(3) + 4 or f(3 + 4)? Precedence can be used, but precedence rules can quickly become confusing. –
Waisted They are identical. I see the parenthesis syntax quite often, and I always ask those who use it: why? And none can answer why they use it.
To bluntly sum it up, parenthesis around returning expressions are used by people who don't quite grasp the difference between function-like macros and functions, or who are confused about the operator precedence or order of evaluation rules in C. There is no coding style benefit from using parenthesis.
Thus
return value;
is more correct than
return (value)
because the latter suggests you don't quite know what you are doing :)
return is a jump statement, not a selection or iteration statement. So it should be compared to goto, break and continue rather than anything else. Do you use parenthesis whenever you use goto, break or continue? If so, how did you even manage that syntax-wise? –
Slope return and if, the formal syntax for return is: return expression ;. The formal syntax for if is if ( expression ). Like it or not, that's how the language was designed. if requires parenthesis by the formal syntax definition. –
Slope Both are the same in your case.
a is 5 then return a++; and return (a++); (which is the same) will both return 5 –
Predicative © 2022 - 2024 — McMap. All rights reserved.
c++/c. It would be good to be more specific on the language definition, but I do not know how to fix that 9 years later. – ClootsCthere is a duplicate #162379 – Cloots