void func () returning value?

[Yevgen Muntyan]

Hey,

Consider the following code:

void func (void)
{
}

void func2 (void)
{
return func ();
}

gcc -pedantic says the following:

muntyan@munt10:/tmp$ gcc -pedantic -c file.c
file.c: In function ‘func2’:
file.c:7: warning: ‘return’ with a value, in function returning void

If I recall correctly, compiler in some Microsoft Visual Studio version
told me the same thing. So, is this a compiler bug (feature), or is this
"return func ();" invalid in standard C?

Thanks,
Yevgen

[Harald van Dijk]

Yevgen Muntyan wrote:

Hey,

Consider the following code:

void func (void)
{
}

void func2 (void)
{
return func ();
}

gcc -pedantic says the following:

muntyan@munt10:/tmp$ gcc -pedantic -c file.c
file.c: In function ‘func2’:
file.c:7: warning: ‘return’ with a value, in function returning void

If I recall correctly, compiler in some Microsoft Visual Studio version
told me the same thing. So, is this a compiler bug (feature), or is this
"return func ();" invalid in standard C?

It's invalid in standard C. Perhaps you're thinking of C++, where it is
allowed?

[Nick Keighley]

Harald van Dijk wrote:

Yevgen Muntyan wrote:

Consider the following code:

void func (void)
{
}

void func2 (void)
{
return func ();
}

gcc -pedantic says the following:

muntyan@munt10:/tmp$ gcc -pedantic -c file.c
file.c: In function ‘func2’:
file.c:7: warning: ‘return’ with a value, in function returning void

If I recall correctly, compiler in some Microsoft Visual Studio version
told me the same thing. So, is this a compiler bug (feature), or is this
"return func ();" invalid in standard C?

It's invalid in standard C. Perhaps you're thinking of C++, where it is
allowed?

since when has it been valid for a void function to return a value, in
either C or C++?
--
Nick Keighley

[Greg]

Nick Keighley wrote:

Harald van Dijk wrote:

Yevgen Muntyan wrote:

Consider the following code:
>
void func (void)
{
}
>
void func2 (void)
{
return func ();
}
>
gcc -pedantic says the following:
>
muntyan@munt10:/tmp$ gcc -pedantic -c file.c
file.c: In function ‘func2’:
file.c:7: warning: ‘return’ with a value, in functionreturning void
>
If I recall correctly, compiler in some Microsoft Visual Studio version
told me the same thing. So, is this a compiler bug (feature), or is this
"return func ();" invalid in standard C?

It's invalid in standard C. Perhaps you're thinking of C++, where it is
allowed?

since when has it been valid for a void function to return a value, in
either C or C++?

It's not legal in C++ for a "return" statement of a void function to
return a value [§6.6.3]. The above program is nonetheless OK since it
is legal in C++ for a return statement in a void function to have a
(cv) void type expression - as in this case, the return expression is
simply a call to another void function.

Greg

[Risto Lankinen]

"Nick Keighley" <ni******************@hotmail.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...

>since when has it been valid for a void function to return a value, in
either C or C++?

A void function can "return" an expression whose type is void . This
is to facilitate templates such as...

template <typename TT func() { return static_cast<T>(expr); }

.... to be instantiable also for T=void.

- Risto -

--
Nick Keighley

[Yevgen Muntyan]

Harald van Dijk wrote:

Yevgen Muntyan wrote:

>>Hey,

Consider the following code:

void func (void)
{
}

void func2 (void)
{
return func ();
}

gcc -pedantic says the following:

muntyan@munt10:/tmp$ gcc -pedantic -c file.c
file.c: In function ‘func2’:
file.c:7: warning: ‘return’ with a value, in function returning void

If I recall correctly, compiler in some Microsoft Visual Studio version
told me the same thing. So, is this a compiler bug (feature), or is this
"return func ();" invalid in standard C?

It's invalid in standard C. Perhaps you're thinking of C++, where it is
allowed?

I am sure I was thinking about C :)
After comparing C and C++ standards it looks like it's a useful C++
feature which wasn't backported to C standard. I thought it was
natural to do 'return func()' for func() returning nothing, but
now I'm curious if there are other languages where it's valid
(I could swear it's so in one of languages I know and where function
can really return nothing, but it's not the case).

Best regards,
Yevgen

[mark_bluemel]

Yevgen Muntyan wrote:

After comparing C and C++ standards it looks like it's a useful C++
feature which wasn't backported to C standard.

For some value of "useful"...

BTW: are you implying that C is, or should be, a subset of C++?
That would, I suspect, be "fighting talk" :-)

I thought it was
natural to do 'return func()' for func() returning nothing,

I thought it was unnatural - funny how people's interpretation of
"natural" varies...

[Yevgen Muntyan]

ma**********@pobox.com wrote:

Yevgen Muntyan wrote:

>>After comparing C and C++ standards it looks like it's a useful C++
feature which wasn't backported to C standard.

For some value of "useful"...

void foo (void)
{
...
for (i = 0; i < 42; ++i)
if (bar (i))
return simple_foo (i);
real_foo_here();
}

Using two statements (function call and return) makes it lot
uglier for me - bunch of curly brackets added. Not a real problem,
of course, but I find "return void_func();" very nice.

BTW: are you implying that C is, or should be, a subset of C++?
That would, I suspect, be "fighting talk" :-)

No, of course no, I think that C++ is a superset of C ;)
Seriously speaking, // comments are a (useful, I think) C++
feature "backported" to C, aren't they? I absolutely didn't mean
"C sucks because C++...." or "C++ is so much nicer because..."

Best regards,
Yevgen

[mark_bluemel]

Yevgen Muntyan wrote:

void foo (void)
{
...
for (i = 0; i < 42; ++i)
if (bar (i))
return simple_foo (i);
real_foo_here();
}

Using two statements (function call and return) makes it lot
uglier for me - bunch of curly brackets added. Not a real problem,
of course, but I find "return void_func();" very nice.

As a predominantly maintenance programmer, I would immediately have
changed your code to

void foo (void)
{
...
for (i = 0; i < 42; ++i) {
if (bar (i)) {
return simple_foo (i);
}
}
real_foo_here();
}

for starters, so splitting function call and return into two lines is
not a big overhead. Leaving braces out is a recipe for future bugs
IMHO....

I stick to my opinion that "void foo()" means that "foo()" doesn't
return anything, so combining an arbitrary call to a void function with
the return is fairly stupid. If you wanted to call something and ignore
its result would you do (for example) 'return (void)printf("My Dog Has
Fleas\n");' ?

As for "//" for comments, I'm rather inclined to prefer "/* ... */" but
that's a personal thing, I guess

[Fred Kleinschmidt]

<ma**********@pobox.comwrote in message
news:11**********************@m7g2000cwm.googlegro ups.com...

>
Yevgen Muntyan wrote:

>void foo (void)
{
...
for (i = 0; i < 42; ++i)
if (bar (i))
return simple_foo (i);
real_foo_here();
}

Using two statements (function call and return) makes it lot
uglier for me - bunch of curly brackets added. Not a real problem,
of course, but I find "return void_func();" very nice.

As a predominantly maintenance programmer, I would immediately have
changed your code to

void foo (void)
{
...
for (i = 0; i < 42; ++i) {
if (bar (i)) {
return simple_foo (i);
}
}
real_foo_here();
}

for starters, so splitting function call and return into two lines is
not a big overhead. Leaving braces out is a recipe for future bugs
IMHO....

I stick to my opinion that "void foo()" means that "foo()" doesn't
return anything, so combining an arbitrary call to a void function with
the return is fairly stupid. If you wanted to call something and ignore
its result would you do (for example) 'return (void)printf("My Dog Has
Fleas\n");' ?

As for "//" for comments, I'm rather inclined to prefer "/* ... */" but
that's a personal thing, I guess

I would have changed it to:

void foo (void)
{
...
for (i = 0; i < 42; ++i) {
if (bar (i)) {
simple_foo (i);
return;
}
}
real_foo_here();
}

Think what would happen if simple_foo() werre changed
to return a value (an error code, of perhaps something else
that foo() is not interested in). If you instead used
return simple_foo(i)
then suddenly the program would not compile.

Now, this may or may not be a reasonable thing.
The compile error would certainly warn you that
perhaps you should pay attention to the return value
of the modified simple_foo() function.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Software Reuse Project

[Al Balmer]

On Wed, 18 Oct 2006 09:43:18 GMT, Yevgen Muntyan
<mu****************@tamu.eduwrote:

>Harald van D?k wrote:

>Yevgen Muntyan wrote:

>>>Hey,

Consider the following code:

void func (void)
{
}

void func2 (void)
{
return func ();
}

gcc -pedantic says the following:

muntyan@munt10:/tmp$ gcc -pedantic -c file.c
file.c: In function ‘func2’:
file.c:7: warning: ‘return’ with a value, in function returning void

If I recall correctly, compiler in some Microsoft Visual Studio version
told me the same thing. So, is this a compiler bug (feature), or is this
"return func ();" invalid in standard C?

It's invalid in standard C. Perhaps you're thinking of C++, where it is
allowed?

I am sure I was thinking about C :)
After comparing C and C++ standards it looks like it's a useful C++
feature which wasn't backported to C standard.

In C, it's a trivial transformation to

func();
return;

What's useful about it? (Aside from possible use in obfuscation.)

I thought it was
natural to do 'return func()' for func() returning nothing, but
now I'm curious if there are other languages where it's valid
(I could swear it's so in one of languages I know and where function
can really return nothing, but it's not the case).

Best regards,
Yevgen

--
Al Balmer
Sun City, AZ

[Richard]

"Harald van Dijk" <tr*****@gmail.comwrites:

Yevgen Muntyan wrote:

>Hey,

Consider the following code:

void func (void)
{
}

void func2 (void)
{
return func ();
}

gcc -pedantic says the following:

muntyan@munt10:/tmp$ gcc -pedantic -c file.c
file.c: In function ‘func2’:
file.c:7: warning: ‘return’ with a value, in function returning void

If I recall correctly, compiler in some Microsoft Visual Studio version
told me the same thing. So, is this a compiler bug (feature), or is this
"return func ();" invalid in standard C?

It's invalid in standard C. Perhaps you're thinking of C++, where it is
allowed?

It is also bad practice IMO.

When reading the code you would immediately assume that func()
is returning a required value.

I have also found in years of modifying large legacy code bases that
"return func()" is not as easy to monitor and debug as "rc= func();
return rc;". Admittedly a personal preference built up from my own
experiences.

[Elijah Cardon]

"Richard" <rg****@gmail.comwrote in message
news:87************@gmail.com...

"Harald van D?k" <tr*****@gmail.comwrites:

>Yevgen Muntyan wrote:

>>Hey,

Consider the following code:

void func (void)
{
}

void func2 (void)
{
return func ();
}

gcc -pedantic says the following:

muntyan@munt10:/tmp$ gcc -pedantic -c file.c
file.c: In function 'func2':
file.c:7: warning: 'return' with a value, in function returning void

If I recall correctly, compiler in some Microsoft Visual Studio version
told me the same thing. So, is this a compiler bug (feature), or is this
"return func ();" invalid in standard C?

It's invalid in standard C. Perhaps you're thinking of C++, where it is
allowed?

It is also bad practice IMO.

When reading the code you would immediately assume that func()
is returning a required value.

I have also found in years of modifying large legacy code bases that
"return func()" is not as easy to monitor and debug as "rc= func();
return rc;". Admittedly a personal preference built up from my own
experiences.

Why do people TRY to find bad logic scenarios with the C Programming
Language. You have two void functions and try to return a call to the first
in the second. If a compiler didn't scream, I would. EC

[Yevgen Muntyan]

Fred Kleinschmidt wrote:

<ma**********@pobox.comwrote in message
news:11**********************@m7g2000cwm.googlegro ups.com...

>>Yevgen Muntyan wrote:

>>>void foo (void)
{
...
for (i = 0; i < 42; ++i)
if (bar (i))
return simple_foo (i);
real_foo_here();
}

Using two statements (function call and return) makes it lot
uglier for me - bunch of curly brackets added. Not a real problem,
of course, but I find "return void_func();" very nice.

As a predominantly maintenance programmer, I would immediately have
changed your code to

void foo (void)
{
...
for (i = 0; i < 42; ++i) {
if (bar (i)) {
return simple_foo (i);
}
}
real_foo_here();
}

for starters, so splitting function call and return into two lines is
not a big overhead. Leaving braces out is a recipe for future bugs
IMHO....

I stick to my opinion that "void foo()" means that "foo()" doesn't
return anything, so combining an arbitrary call to a void function with
the return is fairly stupid. If you wanted to call something and ignore
its result would you do (for example) 'return (void)printf("My Dog Has
Fleas\n");' ?

As for "//" for comments, I'm rather inclined to prefer "/* ... */" but
that's a personal thing, I guess

I would have changed it to:

void foo (void)
{
...
for (i = 0; i < 42; ++i) {
if (bar (i)) {
simple_foo (i);
return;
}
}
real_foo_here();
}

Think what would happen if simple_foo() werre changed
to return a value (an error code, of perhaps something else
that foo() is not interested in). If you instead used
return simple_foo(i)
then suddenly the program would not compile.

Yes, exactly. Compiler will complain if either foo or simple_foo
change return value from void to something. And it is a really
good thing.

Regards,
Yevgen

[Yevgen Muntyan]

ma**********@pobox.com wrote:

Yevgen Muntyan wrote:

>>void foo (void)
{
...
for (i = 0; i < 42; ++i)
if (bar (i))
return simple_foo (i);
real_foo_here();
}

Using two statements (function call and return) makes it lot
uglier for me - bunch of curly brackets added. Not a real problem,
of course, but I find "return void_func();" very nice.

As a predominantly maintenance programmer, I would immediately have
changed your code to

void foo (void)
{
...
for (i = 0; i < 42; ++i) {
if (bar (i)) {
return simple_foo (i);
}
}
real_foo_here();
}

for starters, so splitting function call and return into two lines is
not a big overhead. Leaving braces out is a recipe for future bugs
IMHO....

If I got this piece of code (with split return statement), I would
change it to:

void foo (void)
{
...
for (i = 0; i < 42; ++i)
{
if (bar (i))
{
simple_foo ();
return;
}
}
real_foo_here();
}

And *here* brackets are no good if you can do without them at all.
A nitpick/rationale: your coding style forces you to always use brackets
since you can't clearly see if there is an opening bracket, so closing
bracket alone is easily lost, and "Leaving braces out is a recipe for
future bugs". In mine, I can easily *see* that I need to add brackets if
I suddenly add a statement. Hope it will not start yet another flame
war on coding style ;)

I stick to my opinion that "void foo()" means that "foo()" doesn't
return anything, so combining an arbitrary call to a void function with
the return is fairly stupid. If you wanted to call something and ignore
its result would you do (for example) 'return (void)printf("My Dog Has
Fleas\n");' ?

No, I wouldn't. Because this cast hides return value, so it's dangerous.
In case with void-void compiler will warn me if some function changes
return type, so I'm safe.

>
As for "//" for comments, I'm rather inclined to prefer "/* ... */" but
that's a personal thing, I guess

Sure it is.

Best regards,
Yevgen

[Andrey Tarasevich]

ma**********@pobox.com wrote:

...

>I thought it was
natural to do 'return func()' for func() returning nothing,

I thought it was unnatural - funny how people's interpretation of
"natural" varies...
...

It is more about the ability to recognize "natural" where it is indeed present.
Someone already demonstrated an example of C++ template code that shows where
this feature can be extremely useful. However, it is absolutely unnecessary to
drag C++ and templates here for that purpose, because C language already has
everything necessary to achieve the level of generality that makes that feature
useful. The example follows

typedef int T;

T foo() { ... };
T bar() { return foo(); }
T baz() { return foo(); }
In at some point in the future I might decide to change the typedef to

typedef void T;

I'll have to comb through the entire program's source code and break all such
return statements into two lines. (And repeat the whole thing again when I
decide to change it back). That is heavily UNnatural. The support for "return
void" would solve the problem in a very elegant way.

So the feature in indeed objectively natural, but unfortunately it is not even
in C99.

--
Best regards,
Andrey Tarasevich

[Yevgen Muntyan]

Richard wrote:

"Harald van Dijk" <tr*****@gmail.comwrites:

>>Yevgen Muntyan wrote:

>>>Hey,

Consider the following code:

void func (void)
{
}

void func2 (void)
{
return func ();
}

gcc -pedantic says the following:

muntyan@munt10:/tmp$ gcc -pedantic -c file.c
file.c: In function ‘func2’:
file.c:7: warning: ‘return’ with a value, in function returning void

If I recall correctly, compiler in some Microsoft Visual Studio version
told me the same thing. So, is this a compiler bug (feature), or is this
"return func ();" invalid in standard C?

It's invalid in standard C. Perhaps you're thinking of C++, where it is
allowed?

It is also bad practice IMO.

When reading the code you would immediately assume that func()
is returning a required value.

Right, and required value in this case is "no value", at least
it's how I read it (and what gcc takes care of).

I have also found in years of modifying large legacy code bases that
"return func()" is not as easy to monitor and debug as "rc= func();
return rc;". Admittedly a personal preference built up from my own
experiences.

It's true, for stepping through the code in debugger split return
statement is better. But "return result_of_this_function_call();"
is so natural, and so easy to read, and doesn't require a dummy
"retval" variable; it's really a good thing. Even standard thinks
it's okay to do it :)

Regards,
Yevgen

[Andrey Tarasevich]

Richard wrote:

>...
It's invalid in standard C. Perhaps you're thinking of C++, where it is
allowed?

It is also bad practice IMO.

When reading the code you would immediately assume that func()
is returning a required value.
...

Well, it depends on how you look at it. I'd say it is actually a good practice
because in this case the code format emphasizes the intent to completely
delegate the flow to another function, in uniform fashion for both void and
non-void functions.

--
Best regards,
Andrey Tarasevich

[Christopher Benson-Manica]

Andrey Tarasevich <an**************@hotmail.comwrote:

typedef int T;

T foo() { ... };
T bar() { return foo(); }
T baz() { return foo(); }

In at some point in the future I might decide to change the typedef to

typedef void T;

In which case you're still SOL when it comes to the uses of bar() and
baz(), which probably look something like

if( bar() ) {
/* ... */
}

or

int quux;
/* ... */
quux = baz();

I'll have to comb through the entire program's source code and break all such
return statements into two lines. (And repeat the whole thing again when I
decide to change it back). That is heavily UNnatural. The support for "return
void" would solve the problem in a very elegant way.

It works a little bit more conveniently if you go from void to a real
type (since in that case bar() and baz() simply return a value that is
immediately discarded), but refactoring one or more functions to
return void when they previously returned a type is unlikely to be
helpful unless the return values were being ignored anyway, in which
case it was probably obvious that they should return void from the
beginning.

So the feature in indeed objectively natural, but unfortunately it is not even
in C99.

I don't really agree that it would be all that useful, unless you can
come up with a different example. I think the

return func_returning_void();

constructs that would thus be allowed would be confusing in any case,
so I can't say I'm sorry not to see this support in C99.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Richard Bos]

Yevgen Muntyan <mu****************@tamu.eduwrote:

ma**********@pobox.com wrote:

Yevgen Muntyan wrote:

>After comparing C and C++ standards it looks like it's a useful C++
feature which wasn't backported to C standard.

For some value of "useful"...

void foo (void)
{
...
for (i = 0; i < 42; ++i)
if (bar (i))
return simple_foo (i);
real_foo_here();
}

Using two statements (function call and return) makes it lot
uglier for me - bunch of curly brackets added. Not a real problem,
of course, but I find "return void_func();" very nice.

Tastes differ. I find it horrible. You're using a single statement to do
two things which are not related to one another. That's not good
practice, and it's not efficient (in fact, it's likely to throw some
optimisers off the scent); all it is is faux-hacker kewl.

Richard

[William Hughes]

Andrey Tarasevich wrote:

ma**********@pobox.com wrote:

...

I thought it was
natural to do 'return func()' for func() returning nothing,

I thought it was unnatural - funny how people's interpretation of
"natural" varies...
...

It is more about the ability to recognize "natural" where it is indeed present.
Someone already demonstrated an example of C++ template code that shows where
this feature can be extremely useful. However, it is absolutely unnecessary to
drag C++ and templates here for that purpose, because C language already has
everything necessary to achieve the level of generality that makes that feature
useful. The example follows

typedef int T;

T foo() { ... };
T bar() { return foo(); }
T baz() { return foo(); }
In at some point in the future I might decide to change the typedef to

typedef void T;

I'll have to comb through the entire program's source code and break all such
return statements into two lines. (And repeat the whole thing again when I
decide to change it back). That is heavily UNnatural. The support for "return
void" would solve the problem in a very elegant way.

So the feature in indeed objectively natural, but unfortunately it is not even
in C99.

Changing a typedef is a *very* dangerous thing to do. Unless the
change is fairly minor (e.g. one int width to another) and/or planned
on when designing the code, it is likely to lead to disaster.
Even at the best of times it is hardly "safe".

Changing a return value from non-void to void is so likely to
cause disaster that I would never do it, unless I had designed
my code to allow this from the start (In which case I would
have to turn handsprings to allow myself to use the possible
return value safely.)

This is not a good argument for allowing void functions
to return a parameter of type void.

- William Hughes

[Yevgen Muntyan]

Richard Bos wrote:

Yevgen Muntyan <mu****************@tamu.eduwrote:

>>ma**********@pobox.com wrote:

>>>Yevgen Muntyan wrote:
After comparing C and C++ standards it looks like it's a useful C++
feature which wasn't backported to C standard.

For some value of "useful"...

void foo (void)
{
...
for (i = 0; i < 42; ++i)
if (bar (i))
return simple_foo (i);
real_foo_here();
}

Using two statements (function call and return) makes it lot
uglier for me - bunch of curly brackets added. Not a real problem,
of course, but I find "return void_func();" very nice.

Tastes differ. I find it horrible.

This is totally fine.

You're using a single statement to do
two things which are not related to one another.

Exactly the same can be said about "return non_void_func();"
(actually, this case is even more about two things - it also
returns value). Do you find

int foo1 (int a)
{
return a + 8;
}

int foo (int a)
{
if (a < 0)
return foo1 (-a);
else
return 8;
}

also terrible? If your answer is "yes", then we are talking about
a bit different things: you don't like some practice allowed by
standard and used a lot in real code, and I don't like standard
not allowing to use this practice in uniform way regardless of
function return value. If your answer is "no", then you'd need
to explain how "return value();" is one thing and "return void_func();"
is "two things".

That's not good
practice, and it's not efficient (in fact, it's likely to throw some
optimisers off the scent);

Maybe, does it matter (the efficiency part)? How much worse is it? Or,
in what/how many cases "return void_func();" affects program
performance, amount of memory it consumes, or whatever else is meant by
"efficient".

Best regards,
Yevgen

[Andrey Tarasevich]

William Hughes wrote:

...
Changing a typedef is a *very* dangerous thing to do. Unless the
change is fairly minor (e.g. one int width to another) and/or planned
on when designing the code, it is likely to lead to disaster.
Even at the best of times it is hardly "safe".

Changing a return value from non-void to void is so likely to
cause disaster that I would never do it, unless I had designed
my code to allow this from the start (In which case I would
have to turn handsprings to allow myself to use the possible
return value safely.)
...

This is the case when the "general case" arguments don't really apply. It all
depends on the typedef itself and why it was introduced in the first place (but
that is essentially what you are saying yourself). In generic code ("template"
code, if you will, which can actually be used in C, even though it doesn't
provide any C++-like template support) a typedef name might be introduced for
the very purpose of being easily changeable between a wide range of types.

And, firstly, in many cases there's no need to "turn handsprings" for that. And,
secondly, even if there is, it might be worth it.

...
This is not a good argument for allowing void functions
to return a parameter of type void.
...

Well, this is not a feature that can possibly have "good" arguments for or
against it. It is just one of those things that allows certain freedom of
personal preference. Some people never use 'do/while' cycles and believe theres'
no "good" argument for them to be in the language. I, for one, do use 'do/while'
cycles.

--
Best regards,
Andrey Tarasevich

[William Hughes]

Andrey Tarasevich wrote:

William Hughes wrote:

...
Changing a typedef is a *very* dangerous thing to do. Unless the
change is fairly minor (e.g. one int width to another) and/or planned
on when designing the code, it is likely to lead to disaster.
Even at the best of times it is hardly "safe".

Changing a return value from non-void to void is so likely to
cause disaster that I would never do it, unless I had designed
my code to allow this from the start (In which case I would
have to turn handsprings to allow myself to use the possible
return value safely.)
...

This is the case when the "general case" arguments don't really apply. It all
depends on the typedef itself and why it was introduced in the first place (but
that is essentially what you are saying yourself). In generic code ("template"
code, if you will, which can actually be used in C, even though it doesn't
provide any C++-like template support) a typedef name might be introduced for
the very purpose of being easily changeable between a wide range of types.

Pehaps you could provide an example of what you mean?

- William Hughes

[Andrey Tarasevich]

William Hughes wrote:

>...
This is the case when the "general case" arguments don't really apply. It all
depends on the typedef itself and why it was introduced in the first place (but
that is essentially what you are saying yourself). In generic code ("template"
code, if you will, which can actually be used in C, even though it doesn't
provide any C++-like template support) a typedef name might be introduced for
the very purpose of being easily changeable between a wide range of types.

Pehaps you could provide an example of what you mean?
...

Well, I can. But what's the purpose of doing that when, I'm afraid, I'll just
get a bunch of replies stating that the same can be done with a separate
function-call statement and return statement? (Which, of course, I know and
which, of course, is completely beside the point).

--
Best regards,
Andrey Tarasevich

[Richard Harter]

On Thu, 19 Oct 2006 08:49:57 GMT, rl*@hoekstra-uitgeverij.nl (Richard
Bos) wrote:

>Tastes differ. I find it horrible. You're using a single statement to do
two things which are not related to one another. That's not good
practice, and it's not efficient (in fact, it's likely to throw some
optimisers off the scent); all it is is faux-hacker kewl.

Why on Earth should it be any less efficient?

I disagree that the two things are unrelated. When you invoke a
function as the argument in a return statement (not quite the right
wording but I trust that you know what I mean) it establishes that the
invoked function is an epilog, i.e., the very last thing that is done
before actually returning control to the parent function.

It's similar to using
a++;
instead of
a = a+1;

In each case you are using one form to force to things to happen
together. In the first case you are calling a function and returning
its result; in the second case you adding one to the value of a
variable and storing it in the variable. In each case you are
eliminating degrees of freedom. The general cases are:

a = foo();
return b;

b = a+1;

One degree of freedom disappears when b and a are identical, i.e.,

a = foo();
return a;

a = a+1;

So we have a special case where a degree of freedom is missing but the
form doesn't make that obvious; this creates a potential source of
error. There is a (rather small?) advantage to using a form that
reflects that actual number of degrees of freedom, e.g.,

return foo();

a++;

All of that said, the whole thing is a bit of a tempest in a teapot.

[William Hughes]

Andrey Tarasevich wrote:

William Hughes wrote:

...
This is the case when the "general case" arguments don't really apply. It all
depends on the typedef itself and why it was introduced in the first place (but
that is essentially what you are saying yourself). In generic code ("template"
code, if you will, which can actually be used in C, even though it doesn't
provide any C++-like template support) a typedef name might be introduced for
the very purpose of being easily changeable between a wide range of types.

Pehaps you could provide an example of what you mean?
...

Well, I can. But what's the purpose of doing that when, I'm afraid, I'll just
get a bunch of replies stating that the same can be done with a separate
function-call statement and return statement? (Which, of course, I know and
which, of course, is completely beside the point).

Not completely. You argue that the ability of void functions to return
void
functions should be added to the C language. Unless you want to argue
that
this looks prettier (in which case "De gustibus non est disputandum"
holds,
with the proviso that making any change to the language is not cost
free
even when a new standard is being brought out) you need to show an
example where the separate function call and return statement would
be impossible or less elegant. You have claimed that such a situation
would arise in "template like" code, but have not given an example.
If indeed, as you suggest, the single return statement can be replaced
by separate function call and return statements even in "template like
code", your argument that it was an error to leave this out of C99 is
weak.
- William Hughes

--
Best regards,
Andrey Tarasevich

[Richard Bos]

Yevgen Muntyan <mu****************@tamu.eduwrote:

Richard Bos wrote:

Yevgen Muntyan <mu****************@tamu.eduwrote:

>void foo (void)
{
...
for (i = 0; i < 42; ++i)
if (bar (i))
return simple_foo (i);
real_foo_here();
}

Using two statements (function call and return) makes it lot
uglier for me - bunch of curly brackets added. Not a real problem,
of course, but I find "return void_func();" very nice.

You're using a single statement to do
two things which are not related to one another.

Exactly the same can be said about "return non_void_func();"
(actually, this case is even more about two things - it also
returns value).

Yes, but those things are related. You compute a value, and then you
return _that_ value. In the void case, you perform a function which does
not deliver any value, and then you return. There is no relation between
the performed function and the return from the calling function, unlike
in the non-void case, where that relation is the computed value.

Richard

[Yevgen Muntyan]

Richard Bos wrote:

Yevgen Muntyan <mu****************@tamu.eduwrote:

>>Richard Bos wrote:

>>>Yevgen Muntyan <mu****************@tamu.eduwrote:
void foo (void)
{
...
for (i = 0; i < 42; ++i)
if (bar (i))
return simple_foo (i);
real_foo_here();
}

Using two statements (function call and return) makes it lot
uglier for me - bunch of curly brackets added. Not a real problem,
of course, but I find "return void_func();" very nice.

>>>You're using a single statement to do
two things which are not related to one another.

Exactly the same can be said about "return non_void_func();"
(actually, this case is even more about two things - it also
returns value).

Yes, but those things are related. You compute a value, and then you
return _that_ value. In the void case, you perform a function which does
not deliver any value, and then you return. There is no relation between
the performed function and the return from the calling function, unlike
in the non-void case, where that relation is the computed value.

Well, "val = func(); return val;" does exactly same thing as "return
func();", still they are different. The "you perform a function which
does not deliver any value, and then you return" is correct but not
quite, it's more "you perform a function, and then you return
*immediately*".

Consider this:

=============================
void func (int *in_arg)
{
...
}

void func2 (int *in_arg)
{
return func (in_arg);
}
=============================

and

=============================
int func (int arg)
{
...
}

int func2 (int arg)
{
return func (arg);
}
=============================

There is no return value in the first case; but in both cases
the "return func();" do exactly same thing - they transfer control
to func(); it's kind of "goto func".

Best regards,
Yevgen