469,085 Members | 1,051 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,085 developers. It's quick & easy.

Using "return" with parantheses?

Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him :(.

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.

Thank you,
Mike Machuidel

Nov 13 '05 #1
32 6847
In article <3f***********************@news.xs4all.nl>, Mike Machuidel wrote:
Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him :(.

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.

It's not wrong, it's just not needed.

See the FAQ at

http://www.eskimo.com/~scs/C-faq/q20.19.html

--
Andreas Kähäri
Nov 13 '05 #2
Mike Machuidel <ma*******@yahoo.com> wrote:
Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him :(.

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.


There's nothing wrong with it from a technical POV. Some people don't
like it as a style issue, because _they_ are the ones who keep
forgetting that return is not a function if they keep seeing the parens,
but that's their problem, not yours. FTR, I don't put parens around the
argument of return, but I won't shout at you for doing so.

Richard
Nov 13 '05 #3

"Andreas Kahari" <ak*******@freeshell.org> wrote in message
news:sl**********************@vinland.freeshell.or g...
In article <3f***********************@news.xs4all.nl>, Mike Machuidel

wrote:
Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him :(.

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.

It's not wrong, it's just not needed.

See the FAQ at

http://www.eskimo.com/~scs/C-faq/q20.19.html


Technically whitespace isn't needed by the compiler either [at least to the
extent most people use it, obviously you need to seperate tokens...]

Tom
Nov 13 '05 #4

"Mike Machuidel" <ma*******@yahoo.com> wrote in message
news:3f***********************@news.xs4all.nl...
Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him :(.

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.


It isn't wrong but if your company has standards for coding I suggest you
follow them.

Also "return(0);" does look stupid I'd put a space there "return (0);"

Though I'm against returning constants alltogether. You should have some

enum {
RES_OK,
RES_ERR
};

[etc]

and return RES_OK instead.

Tom
Nov 13 '05 #5
In <3f***********************@news.xs4all.nl> Mike Machuidel <ma*******@yahoo.com> writes:
I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him :(.

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.


There is nothing wrong, if you also write such things:

i = (j) + (k);
for (i = (0); i < (sizeof(foo)); i++) ...
printf("%d\n", (i));

If you don't, then what's the point in surrounding the return
expression by a pair of completely useless parentheses? The language
accepts them for the sole reason that every expression can be
surrounded by an arbitrary number of matching pairs of parentheses
(up to 32 in C89 or 63 in C99). So, why limit yourself at a single
pair, when return(((((((((0))))))))); is so much cooler?

The other reason against parentheses in return statements is related to
what happens if you make a typo. In C89, retunr(0); is a valid function
call that doesn't require any diagnostic, while retunr 0; is a syntax
error requiring a diagnostic. Why prevent the compiler from detecting
and reporting your typos?

In short, in a C program, *unneeded* parentheses should be used only when
they improve the code readability (usually complex expressions). I don't
find return(0) and more readable than return 0 and the previous paragraph
explains why the latter is to be preferred.

During the early days of C, the syntax of the return statement required
the parentheses. Later, it was realised that they don't serve any *good*
purpose and, by the time K&R1 was printed, they were already removed from
the language syntax (but not from the code examples included in the book).
This explains why some people who learned C more than 15 years ago may
still use them.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #6
On Fri, 24 Oct 2003, Mike Machuidel wrote:
Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him :(.

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.
I would never say it is 'wrong' to use:

return(0);

There could be the off chance a utility would see this as a function and
get confused (or maybe a REALLY junior programmer).

One thought could be that junior programmers might assume it is a function
call. To make it clear to everyone, don't use the parentheses so people
know it is not a function call. The same would hold true for the sizeof
operator.

What it really boils down to is people being nitpicky. I'm sure if I
wrote:

return((((((0))))));

that would bother a lot of people. There is nothing really wrong with it.
It just bothers people because there is no need for the parentheses.
Thank you,
Mike Machuidel


--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@whitehouse.gov
Nov 13 '05 #7
"Andreas Kahari" <ak*******@freeshell.org> wrote in message
news:sl**********************@vinland.freeshell.or g...
It's not wrong, it's just not needed.

See the FAQ at

http://www.eskimo.com/~scs/C-faq/q20.19.html


As the FAQ points out, "parentheses are optional with the sizeof operator,
too, as long as its operand is a variable or a unary expression".

When I first started programming in C, I was asked to write a macro, which
would calculate the number of elements in an array, but couldn't use any
functions. I knew I could do it like this:

#define NUM_ELTS(x) (sizeof(x) / sizeof(x[0]))

However, at the time, the parentheses that I was taught to use made me think
that sizeof was a function.

In my opinion, any C programmer who doesn't know that parentheses are
optional in these cases, and others, has no business working on any real
projects other then the ones out of a workbook. Maybe your use of
parentheses suggested to you coworkers a lack of understanding. As you
pointed out, it's not wrong; but, they aren't necessary. What would you
think if a coworker started writing code like this:

int main(void)
{
int a = (32);
printf("%d\n", (a));
return (0);
}

Sean
Nov 13 '05 #8
"Mike Machuidel" <ma*******@yahoo.com> wrote in message
news:3f***********************@news.xs4all.nl...
I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".


I'm dying to know, how old is that programmer?
Nov 13 '05 #9
On Fri, 24 Oct 2003 10:13:57 -0400, Fao, Sean wrote:
In my opinion, any C programmer who doesn't know that parentheses are
optional in these cases, and others, has no business working on any real
projects other then the ones out of a workbook. Maybe your use of
parentheses suggested to you coworkers a lack of understanding. As you
pointed out, it's not wrong; but, they aren't necessary. What would you
think if a coworker started writing code like this:

int main(void)
{
int a = (32);
printf("%d\n", (a));
return (0);
}


Probably the same as if a found a coworker who had written...

if (a && b || c && d != -1)

....parentheses are mainly about style, and yes examples can be provided at
either extreme that are terrible. Personally I find that I think of...

if (x)
while (x)
switch (x)
return (x)
exit (x)

....all as "similar" so I make them look the same. I also, personally, find
that I think of...

strlen(x)
sizeof(x)
malloc(x)

....as "similar", so I make them look the same. That doesn't mean I don't
understand that sizeof() isn't a real function (even though it's even
closer to acting like one in C99), I just prefer to see it that way.

As was said, if you have coding stds. for what you are working on then
almost any style applied consistently is better than a mixture of
anything. So if the rest of the code base used non-parentheses return
statements then you should change.

As for typing "return (0);" being typoed "reutrn (0);" and not being
caught, then..

1. Every viewer/editor[1] I use for C has syntax highlighting that show the
return as obviously wrong.
2. I've always used a compiler that warns when you use a non-prototyped
function.

[1] Well, ok, every one apart from my newsclient.

--
James Antill -- ja***@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

Nov 13 '05 #10
Mike Machuidel wrote:
Today, at work, a colleague (a C++ programmer) yelled at me.
I'm a bad C programmer
because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a statment,
like I didn't know already.
The other colleagues also agreed with him :(.

Can someone please explain
what's so wrong about using "return" with parentheses?
I've used them like that from the beginning.
cat main.c #define return(value) return value

int main(int argc, char* argv[]) {
return(0);
}
gcc -Wall -std=c99 -pedantic -E main.c

# 1 "main.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "main.c"
int main(int argc, char* argv[]) {
return 0;
}

Nov 13 '05 #11

"Mike Machuidel" <ma*******@yahoo.com> wrote in message
news:3f***********************@news.xs4all.nl...
Hi,

I'm a game developer programming mostly in C and ASM for about 7 years.

Today at work a colleague (a C++ programmer) yelled at me I'm a bad C
programmer because I use "return(0);" instead of "return 0;".
He explained that "return" is not a function but a stament, like I
didn't know already. The other colleagues also argreed with him :(.

Can someone please explain what's so wrong about using "return" with
parantheses? I've used them like that from the beginning.


I sometimes use them. One reason might be that I used to use PL/I, where
they are required for return statements returning a value.

The syntax of if, for, and while, to name a few, C statements, requires
parenthesis and I don't think it makes them look like functions.

In any case, I think putting the return value on the return statement is
better than the traditional Fortran method of assigning to a variable named
after the function. (Though for Fortran implementations with the ENTRY
statement, assigning to a variable is probably better, because of
type/conversion problems.)

-- glen
Nov 13 '05 #12
"James Antill" <ja***********@and.org> wrote in message
news:pa****************************@and.org...
...parentheses are mainly about style, and yes examples can be provided at
either extreme that are terrible.

[...]

Style is a touchy subject because the language rules only provide a starting
ground. I personally hate seeing code with the opening { on the same line
as the if statement, while loops, etc...However, I do like them to be on the
same line as a do and with the while on the same lines as the closing }, for
some reason (don't ask me why, I don't know; I just like it that way). I
don't want to get into an argument over who is right because who's to say I
am? I like how I write my code and that's the reason I do it thay way.
I've also never had a complaint about my style. I just hope that the
company I work for doesn't decide to make any style changes while I'm still
around.

Sean

Nov 13 '05 #13
"Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> writes:
[...]
When I first started programming in C, I was asked to write a macro, which
would calculate the number of elements in an array, but couldn't use any
functions. I knew I could do it like this:

#define NUM_ELTS(x) (sizeof(x) / sizeof(x[0]))

However, at the time, the parentheses that I was taught to use made me think
that sizeof was a function.


I would write that as

#define NUM_ELTS(x) (sizeof(x) / sizeof((x)[0]))

References to macro arguments should always be enclosed in
parentheses; otherwise you can run into some really nasty problems
with operator precedence. Remember that the argument is expanded into
the text, not into the expression tree.

This rule applies to function-like macros whose arguments are
expressions; it may not apply to more bizarre macro definitions.

#include <stdio.h>

#define SIX 1+5
#define NINE 8+1

int main(void)
{
printf("%d * %d = %d\n", SIX, NINE, SIX * NINE);
return 0;
}

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #14
On Fri, 24 Oct 2003 12:43:05 +0200, in comp.lang.c , Mike Machuidel
<ma*******@yahoo.com> wrote:
Hi,

Can someone please explain what's so wrong about using "return" with
parantheses?


There's nothing wrong, they're just not needed. For not particular
reason I tend to use them if the return is a messy expression,
otherwise not.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #15
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in
news:3F**************@jpl.nasa.gov on Fri 24 Oct 2003 02:28:09p:
> cat main.c

#define return(value) return value

int main(int argc, char* argv[]) {
return(0);
}
> gcc -Wall -std=c99 -pedantic -E main.c

# 1 "main.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "main.c"
int main(int argc, char* argv[]) {
return 0;
}


Eh, but if you have to run your code through the pre-processor to make it
conform to your company's standards, you'll probably find yourself on the
short end of the chewed-out stick. After all, at least on my system,
running the pre-processor on any of my code produces something that's full
of odd magic numbers and rather ugly lines of stuff I didn't write.

So, what does your code really prove? We all know the pre-processor phase
comes before the compilation phase.

Nov 13 '05 #16
"August Derleth" <li*****************@onewest.net> wrote in message
news:Xn**********************************@63.223.8 .240...
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in
news:3F**************@jpl.nasa.gov on Fri 24 Oct 2003 02:28:09p:
> cat main.c

#define return(value) return value

int main(int argc, char* argv[]) {
return(0);
}
> gcc -Wall -std=c99 -pedantic -E main.c

# 1 "main.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "main.c"
int main(int argc, char* argv[]) {
return 0;
}


Eh, but if you have to run your code through the pre-processor to make it
conform to your company's standards, you'll probably find yourself on the
short end of the chewed-out stick. After all, at least on my system,
running the pre-processor on any of my code produces something that's full
of odd magic numbers and rather ugly lines of stuff I didn't write.

So, what does your code really prove? We all know the pre-processor phase
comes before the compilation phase.

You are right in your statements, but wrong in reasoning. We all
know that preprocessing phase comes *after* reviewing phase ;-)
It's about human readers of code, compiler doesn't care about
parentheses in this particular case, and proposed "solution" only
adds more useless clutter into code.

OTOH, I've seen ([sur]real code in [sur]real system) something like:

#define return(x) \
{ \
printf("%d\n", x); \
/* 10 or so lines of "debugging" code */
return 0; \
}

In order to use this "facility", return *had* to be coded with parentheses
around value. If that was a good practice is beside the point on hand.
Nov 13 '05 #17
Fao, Sean <en**********@yahoo.comi-want-no-spam> scribbled the following:
In my opinion, any C programmer who doesn't know that parentheses are
optional in these cases, and others, has no business working on any real
projects other then the ones out of a workbook. Maybe your use of
parentheses suggested to you coworkers a lack of understanding. As you
pointed out, it's not wrong; but, they aren't necessary. What would you
think if a coworker started writing code like this: int main(void)
{
int a = (32);
printf("%d\n", (a));
return (0);
}


Your printf statement has too few parantheses. It's much more legible
as:

(printf)(("%d\n"), (a));

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
Nov 13 '05 #18
August Derleth wrote:
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote
> cat main.c
.... snip ...
So, what does your code really prove? We all know the
pre-processor phase comes before the compilation phase.


It proves him to be a troll. If we all ignore him, apart from
correcting the persistent errors, maybe he will go away.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #19
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bn**********@oravannahka.helsinki.fi...
Your printf statement has too few parantheses. It's much more legible
as:

(printf)(("%d\n"), (a));


You missed one too ;-)

((printf)(("%d\n"), (a)));

Nov 13 '05 #20
Fao, Sean <en**********@yahoo.comi-want-no-spam> scribbled the following:
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bn**********@oravannahka.helsinki.fi...
Your printf statement has too few parantheses. It's much more legible
as:

(printf)(("%d\n"), (a));
You missed one too ;-) ((printf)(("%d\n"), (a)));


Good catch!

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr
Nov 13 '05 #21

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bn**********@oravannahka.helsinki.fi...
Fao, Sean <en**********@yahoo.comi-want-no-spam> scribbled the following:
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bn**********@oravannahka.helsinki.fi...
Your printf statement has too few parantheses. It's much more legible
as:

(printf)(("%d\n"), (a));

You missed one too ;-)

((printf)(("%d\n"), (a)));


Good catch!


Wow you're fast! I just sent that like 10 seconds ago!

Nov 13 '05 #22
Fao, Sean wrote:
You missed one too ;-)

((printf)(("%d\n"), (a)));


Uhm. One more level of parenthesis and your C code could be compiled by
a lisp compiler :-)

Nov 13 '05 #23
In <qchmb.9047$9E1.40254@attbi_s52> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

The syntax of if, for, and while, to name a few, C statements, requires
parenthesis and I don't think it makes them look like functions.


That's because something else is *usually* following the right
parenthesis. And even when there is nothing else, many people prefer
to write the semicolon on a separate line.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #24
In <pa****************************@and.org> James Antill <ja***********@and.org> writes:
As for typing "return (0);" being typoed "reutrn (0);" and not being
caught, then..

1. Every viewer/editor[1] I use for C has syntax highlighting that show the
return as obviously wrong.
2. I've always used a compiler that warns when you use a non-prototyped
function.


Some day, you may be forced to use a less friendly set of tools (some
people have provided real life examples in this newsgroup). The less
your coding style relies on tools, the more robust it is and it is a fact
that "reutrn 0;" requires a diagnostic, while "reutrn (0);" doesn't (in
C89). All other things being equal, it is downright foolish to ignore
such arguments.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #25
In <mN*******************@news01.bloor.is.net.cable.r ogers.com> "nobody" <no****@nowhere.non> writes:
OTOH, I've seen ([sur]real code in [sur]real system) something like:

#define return(x) \
{ \
printf("%d\n", x); \
/* 10 or so lines of "debugging" code */
return 0; \
}

In order to use this "facility", return *had* to be coded with parentheses
around value. If that was a good practice is beside the point on hand.


Turning keywords into macros is already bad, but giving these macros
misleading semantics is downright atrocious. To inject some sanity into
such a macro, it should look like this:

#define return(x) \
{ \
printf("%d\n", (int)(x)); \
/* 10 or so lines of "debugging" code */ \
return x; \
}

Still has a problem with functions returning structures or unions, but
it requires a compile time diagnostic. And the basic semantics
of return are preserved (the function still returns what it was
supposed to return).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #26
In <lz************@cts.com> Keith Thompson <ks*@cts.com> writes:
"Fao, Sean" <en**********@yahoo.comI-WANT-NO-SPAM> writes:
[...]
When I first started programming in C, I was asked to write a macro, which
would calculate the number of elements in an array, but couldn't use any
functions. I knew I could do it like this:

#define NUM_ELTS(x) (sizeof(x) / sizeof(x[0]))

However, at the time, the parentheses that I was taught to use made me think
that sizeof was a function.


I would write that as

#define NUM_ELTS(x) (sizeof(x) / sizeof((x)[0]))

References to macro arguments should always be enclosed in
parentheses; otherwise you can run into some really nasty problems
with operator precedence. Remember that the argument is expanded into
the text, not into the expression tree.


Care to provide a concrete example of a *correct* NUM_ELTS() invocation
where the extra parentheses make any difference?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #27

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bn**********@sunnews.cern.ch...
In <qchmb.9047$9E1.40254@attbi_s52> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:
The syntax of if, for, and while, to name a few, C statements, requires
parenthesis and I don't think it makes them look like functions.


That's because something else is *usually* following the right
parenthesis. And even when there is nothing else, many people prefer
to write the semicolon on a separate line.


Yes, and also the difference between languages with, and without, reserved
words.

PL/I doesn't have reserved words, so that procedure calls must either be in
an expression, such as part of an assignment statement, or from a CALL
statement.

But C already confuses the issue between statements and function calls.
The exit() function is similar to the STOP statement in PL/I and Fortran,
though it could be considered related to return. Though I do agree that
having return as a function call would be very strange. It does seem that
exit would make more sense as a statement than a function.

-- glen
Nov 13 '05 #28
Da*****@cern.ch (Dan Pop) writes:
In <lz************@cts.com> Keith Thompson <ks*@cts.com> writes:

[...]
I would write that as

#define NUM_ELTS(x) (sizeof(x) / sizeof((x)[0]))

References to macro arguments should always be enclosed in
parentheses; otherwise you can run into some really nasty problems
with operator precedence. Remember that the argument is expanded into
the text, not into the expression tree.


Care to provide a concrete example of a *correct* NUM_ELTS() invocation
where the extra parentheses make any difference?


I can't think of one, and there may not be one, but I'd much rather
add the parentheses than take the time to convince myself that they're
not necessary in this particular instance.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #29
Glen Herrmannsfeldt wrote:

"Dan Pop" <Da*****@cern.ch> wrote in message
news:bn**********@sunnews.cern.ch...
In <qchmb.9047$9E1.40254@attbi_s52> "Glen Herrmannsfeldt"

<ga*@ugcs.caltech.edu> writes:

The syntax of if, for, and while, to name a few, C statements, requires
parenthesis and I don't think it makes them look like functions.


That's because something else is *usually* following the right
parenthesis. And even when there is nothing else, many people prefer
to write the semicolon on a separate line.


Yes, and also the difference between languages with, and without, reserved
words.

PL/I doesn't have reserved words, so that procedure calls must either be in
an expression, such as part of an assignment statement, or from a CALL
statement.

But C already confuses the issue between statements and function calls.
The exit() function is similar to the STOP statement in PL/I and Fortran,
though it could be considered related to return. Though I do agree that
having return as a function call would be very strange. It does seem that
exit would make more sense as a statement than a function.

Nonetheless, it is a function. Several years ago I examined some C
startup and shutdown. The start: label set up stuff from the command
processor arguments, argc and argv, and then called
'exit(main(argc,argv))'. exit() saved main()'s return value and, after
'closing' the C environment, returned it to the command processor (an
int value). Of course this is annecdotal and may have nothing to do with
C today.
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 13 '05 #30
In <Feenb.42094$Fm2.17840@attbi_s04> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:
But C already confuses the issue between statements and function calls.
The exit() function is similar to the STOP statement in PL/I and Fortran,
though it could be considered related to return.
Can't see much similarity between the exit() function and the return
statement. They perform completely different actions, the only thing
they have in common being that the execution of the current function
is terminated. But, then again, the same is true for the abort(),
longjmp() and _Exit() functions (the latter is a C99 feature).
Though I do agree that
having return as a function call would be very strange. It does seem that
exit would make more sense as a statement than a function.


Then, you'd have to make abort, longjmp and _Exit statements, too, to be
consistent. OTOH, C being neither PL/I nor Fortran, there is precious
little point in using these languages as a model. Next thing, you'll
want all the I/O to be moved from the library to the language proper,
because this is how Fortran does it. And so on...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #31
In <3F***********@earthlink.net> Joe Wright <jo********@earthlink.net> writes:
Nonetheless, it is a function. Several years ago I examined some C
startup and shutdown. The start: label set up stuff from the command
processor arguments, argc and argv, and then called
'exit(main(argc,argv))'. exit() saved main()'s return value and, after
'closing' the C environment, returned it to the command processor (an
int value). Of course this is annecdotal and may have nothing to do with
C today.


It is perfectly consistent with the current C standard. It's just that
that a C99 compiler must be careful to automatically insert a return 0
statement at the end of main, if the execution of main can ever reach that
point. C89 doesn't even require this automatic insertion: exit() will
proceed with whatever garbage comes as the return value of main(), without
invoking undefined behaviour.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #32
In <lz************@cts.com> Keith Thompson <ks*@cts.com> writes:
Da*****@cern.ch (Dan Pop) writes:
In <lz************@cts.com> Keith Thompson <ks*@cts.com> writes:

[...]
>I would write that as
>
>#define NUM_ELTS(x) (sizeof(x) / sizeof((x)[0]))
>
>References to macro arguments should always be enclosed in
>parentheses; otherwise you can run into some really nasty problems
>with operator precedence. Remember that the argument is expanded into
>the text, not into the expression tree.


Care to provide a concrete example of a *correct* NUM_ELTS() invocation
where the extra parentheses make any difference?


I can't think of one, and there may not be one, but I'd much rather
add the parentheses than take the time to convince myself that they're
not necessary in this particular instance.


Then, it's a matter of personal style, rather than one of correctness
(in the context of the macro under discussion). Big difference!

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #33

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.