9

Usually auto-generated c++ "main" function has at the end

return (0);

or

return (EXIT_SUCCESS);

But why there are parentheses in above statements? Is it related to C language or something?

// EDIT

I know this is correct, but someone put these brackets for a reason. What's the reason?!

adf88
  • 4,277
  • 1
  • 23
  • 21

9 Answers9

10

They are not required (even in c). I think some people use them to make 'return' look more like a function call, thinking it is more consistent.

Edit: It's likely the generator does this for it's own reasons. It may be safer or easier for it to work this way.

sje397
  • 41,293
  • 8
  • 87
  • 103
  • But what's the point if it is in generated code ? I thought of it of some kind of protection. – slaphappy Jul 01 '10 at 07:36
  • 3
    Maybe the generated code might contain a semicolon. Then the parenthesized version would cause a compiler error, whereas the non-parenthesized version would fail silently or merely produce a warning. – Philipp Jul 01 '10 at 07:42
  • I find there are a few things I don't like about the particular code generator your are probably referring to...e.g. opening curly braces on the next line. In #defines, it's always good to put brackets around expressions, e.g. `#define X(x) (x-2x)` since it usually helps when you do `3 * X(2)`. I can't think of any good reason to do this for returns. – sje397 Jul 01 '10 at 07:45
  • 4
    A long time ago my mentor said to me loudly and slowly that "return is not a function and it does not have parameters." – Brian Hooper Jul 01 '10 at 09:12
9

But why there are parentheses in above statements? Is it related to C language or something?

No. As far as I can tell, C has never required parentheses for return statements. This appears to have been the case even before the first ANSI C standard.

This is actually a very interesting question, however, as I've seen that style prevalent among certain C programmers.

I think the most likely guess as to why this style came about is because all other branching statements (for, while, if, switch) require parentheses around expressions. People might have been unaware that they could omit the parentheses for return statements or were aware of this but wanted to achieve a more uniform look to their code.

The ternary ?: operator is sort of an exception as it is an operator and doesn't require parentheses around the conditional expression, yet people often write parentheses there as well regardless of whether it's needed. Some might find it serves to 'group' an expression into a single unit visually.

My second best guess is that this style was influenced by other languages popular at the time. However, popular, procedural alternatives at the time like Pascal did not require that syntax either (Pascal did not even have return values in the C sense but only output parameters) so if this is the case, I'm not aware of any particularly language from which this style originated.

[Subjective] I prefer styles that require the least amount of superfluous decoration to the code whether it comes to naming conventions or how to format it or whether to use additional parentheses where unnecessary. I find that any such decoration tends to be a matter of unique personal preference and falling in love with one way of decorating code just means that someday you'll have to deal with a completely different way (unless you work strictly alone, in which case I envy you). [/Subjective]

stinky472
  • 6,737
  • 28
  • 27
  • You pointed out a very good supposition that this can be a remain from older times. If just someone could confirm that ... If this is a case of coding style and extra code decoration then why we can't find this style anywhere else (at least me)? Hmm, maybe this is a relict, some kind of tradition? – adf88 Jul 01 '10 at 08:33
  • @adf88 I would assume so. return expr; and return (expr); will always be the same, however. There could not possibly be a case where it would evaluate to a different result or fail to build without the parentheses, so it's strictly a matter of preference and people today might choose that style for the same reasons that some old school programmers chose that style before (or maybe new programmers are just looking at their code and mimicking it). – stinky472 Jul 01 '10 at 08:44
  • One other possible influential factor relating to the second hypothesis about other languages might be functional languages like lisp or its successors. In lisp, everything follows a strict format where everything is written inside parentheses. This kind of uniformity had a great appeal to some and was hated by others, but those who liked it might have adapted their style in order to achieve a greater sense of visual uniformity in their code when migrating to C. – stinky472 Jul 01 '10 at 08:51
  • @adf88 Philipp pointed out a case I did not think of, and that is a macro with a semilcolon in it. There return (macro) would give a compiler error where return macro; would not (a warning at best). That seems unlikely to explain the prevalence of this style, but it is worthy of note. – stinky472 Jul 01 '10 at 13:35
8

This is actually a requirement for BSD kernel source file style.

man 9 style says:

Space after keywords (if, while, for, return, switch).

and

Values in return statements should be enclosed in parentheses.

greg
  • 4,843
  • 32
  • 47
  • Citing an outfit who use the idiom doesn't answer the question of whether it achieves anything, which it doesn't. Does their style guide even bother attempting to justify this? – underscore_d Jul 30 '16 at 23:54
6

Things changes with the use of decltype(auto) in c++14 to deduce return type. If parentheses are used then returned type is deduced to be a reference:

decltype(auto) foo1() {
   int n;
   return (n); // parentheses causes return type to be int&
}

decltype(auto) foo2() {
   int n;
   return n; // no parentheses causes return type to be int
}

template<typename T> struct TD;

int main()
{
  // main.cpp:19:22: error: aggregate 'TD<int&()> f1' has incomplete type and cannot be defined TD<decltype(foo1)> f1;
  TD<decltype(foo1)> f1;

  // main.cpp:20:22: error: aggregate 'TD<int()> f2' has incomplete type and cannot be defined TD<decltype(foo2)> f2;
  TD<decltype(foo2)> f2;
}
marcinj
  • 48,511
  • 9
  • 79
  • 100
6

As any valid expression can be passed to return, those brackets can be added if desired. It is like doing this:

int i = (0);

You can nest an expression in as many brackets as you like:

return (((((0)))));
Janick Bernet
  • 20,544
  • 2
  • 29
  • 55
3

There's a dumb reason - to make return look more like a function call.

There's a smarter reason - if the code is generated, code generators often "play it safe" by putting parentheses around expressions just so they never have to be concerned about the precedence leaking out.

Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
2

Those are not required. Maybe they come from the tendency to prefer more brackets to fewer brackets when writing macros.

Since you mention auto-generated code it might happen that the code used for generating macros was written by reusing code for generating macros or by a person who thought that more brackets won't hurt, but fewer brackets can be fatal.

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979
2

Just my silly speculation:

#define RETURN(val) { if (val) printf("Main Exit With Error %d\n", val); return val; }

int main(argc, argv)
{
  ...
  RETURN (E_FILENOTFOUND);
}
hichris123
  • 10,145
  • 15
  • 56
  • 70
rwong
  • 6,062
  • 1
  • 23
  • 51
  • The question was about `return`, not `RETURN`... Someone trying to adopt a unified style that would work with both the real keyword and a macro substitution - which would vaguely justify the otherwise useless parentheses - would use the correct case. If using different cases, then surely they could remember only to use the parentheses where necessary. – underscore_d Jul 30 '16 at 23:53
0

One reason I can see for this:

return (ERROR_SUCCESS);

is that it's expressing the concept that ERROR_SUCCESS is opaque. We all know it's 0L, but we shouldn't have to.

That's a fairly weak reason.

Another is that it's aesthetically pleasing to use parentheses for consistency, another weak reason.

So in other words, I don't use it myself, but wouldn't flip out if someone else did. :)

Ryan Ginstrom
  • 13,915
  • 5
  • 45
  • 60
  • How does that "express the concept that `ERROR_SUCCESS` is opaque? What is that even supposed to mean? But whatever it is, parentheses do precisely nothing to change it. – underscore_d Jul 30 '16 at 23:54