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

return (0);


return (EXIT_SUCCESS);

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


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

+8  A: 

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.

But what's the point if it is in generated code ? I thought of it of some kind of protection.
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.
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.
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
+4  A: 

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)))));
You can also do: return (42 - 42);
Alex M.
+2  A: 

Those are not required. Maybe they come from the tendency to prefer more brackets to less 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 less brackets can be fatal.

+5  A: 

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]

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 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).
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.
@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.

One reason I can see for this:


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

Just my silly speculation:

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

int main(argc, argv)

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