return values for void functions

[REH]

The other day I did something like this:

void foo
{
}

void bar()
{
return foo();
}

when I meant to do this:

void foo
{
}

void bar()
{
foo();
return;
}

I was suprised that it worked. Is this legal?

Thanks.

 

[Victor Bazarov]

The other day I did something like this:

void foo
{
}

void bar()
{
return foo();
}

when I meant to do this:

void foo
{
}

void bar()
{
foo();
return;
}

I was suprised that it worked. Is this legal?

Yes.

V

 

[enki]

That is important because if you have a series if if statments. You
can get out of the function when your condition is met. There is also
void func(int &a, int &b, char &c){}

 

[Howard Gardner]

The other day I did something like this:

void foo
{
}

void bar()
{
return foo();
}

when I meant to do this:

void foo
{
}

void bar()
{
foo();
return;
}

I was suprised that it worked. Is this legal?

Thanks.

Yes it is, and the fact that it is lets you cover the case of a function
returning void with code like:

template < typename xResult >
xResult foo(xResult (*fFunc)())
{
return (*fFunc)();
}

instead of making you write a special case that handls functions that
return void, for example:

void foo(void (*fFunc)())
{
*fFunc();
}

Having to write that second case to cover a return type of void would be
a major pain.

 

[REH]

That is important because if you have a series if if statments. You
can get out of the function when your condition is met. There is also
void func(int &a, int &b, char &c){}

I'm not sure what your point is.

 

[E. Robert Tisdale]

The other day I did something like this:

cat foo.cc

void foo { }

void bar(void) {
return foo();
}

g++ -Wall -ansi -pedantic -c foo.cc

foo.cc:1: error: invalid function declaration
foo.cc: In function `void bar()':
foo.cc:4: error: `foo' undeclared (first use this function)
foo.cc:4: error: (Each undeclared identifier \
is reported only once for each function it appears in.)
foo.cc:4: error: return-statement with a value, \
in function returning 'void'

You probably meant:

cat foo.cc

void foo(void) { }

void bar(void) {
return foo();
}

g++ -Wall -ansi -pedantic -c foo.cc
nm foo.o

00000006 T _Z3barv
00000000 T _Z3foov

c++filt _Z3barv bar()
c++filt _Z3foov foo()

when I meant to do this:

void foo(void) { }

void bar(void) {
foo();
return;
}

I was suprised that it worked.

I'm surprised too. My compiler doesn't like it.
Are you "sure" that
you actually compiled the code that you posted?

Is this legal?

You probably shouldn't ask a question like this
in the comp.lang.c++ newsgroup.
Some of our subscribers know a lot about the standards
but the real experts are the compiler developers.
Submit your code to your compiler with options set
for standard error checking and all warnings
and it will tell you whether your code is legal or not.
If you don't trust your compiler, submit your code to
Greg Comeau's free online compiler at

http://www.comeaucomputing.com/tryitout/

The compiler is a *much* more reliable judge of legal C++ code
than "some guy" who subscribes to the comp.lang.c++ newsgroup.

 

[Howard]

REH wrote:


The compiler is a *much* more reliable judge of legal C++ code
than "some guy" who subscribes to the comp.lang.c++ newsgroup.

I think that's a pretty bad assessment. How can someone know if their
compiler is any good (compliant), if they don't themselves know what should
be correct? This newsgroup has some folks who are pretty darn good at
interpreting the standard doc's and presenting the OP with good responses.
Who would you trust, your VC++ 6.0 compiler, or one of the regulars here?
I'd listen to the regulars (and the FAQ), myself.

-some guy

 

[E. Robert Tisdale]

I think that's a pretty bad assessment.
How can someone know if their compiler is any good (compliant)
if they don't themselves know what should be correct?

First of all, there are *no* C++ compiler which comply fully
with the ANSI/ISO standards. The Comeau compilers come very close.
It is practically impossible for programmers to determine
for themselves whether any implementation complies or not.

This newsgroup has some folks
who are pretty darn good at interpreting the standard doc's

And many more who are not.
How to you tell the difference.

and presenting the OP with good responses.
Who would you trust, your VC++ 6.0 compiler, or one of the regulars here?

I *don't* trust the "regulars here".
The comp.lang.c++ newsgroup is *not* the most appropriate forum
to discuss the ANSI/ISO C++ standards or whether or not
any particular implementation complies.
The comp.std.c++ newsgroup is more appropriate.
The comp.std.c++ newsgroup attracts real experts
on the ANSI/ISO C++ standards so contributions
are more likely to be properly vetted.

I'd listen to the regulars (and the FAQ), myself.

That's probably bad advice. The first problem is that
we have no way to determine who the "regulars" are
much less whether or not they have any credentials,
training or experience in C++ compiler implementation.
We have no way to determine whether their interpretations
of the ANSI/ISO standards are correct or not.

 

[Greg Comeau]

The other day I did something like this:

void foo
{
}

void bar()
{
return foo();
}

when I meant to do this:

void foo
{
}

void bar()
{
foo();
return;
}

I was suprised that it worked. Is this legal?

Notwithstanding that your foo above is defined incorrectly,
yes, it's legal. Section 6.6.3p3 of Standard C++ reads:
"A return statement with an expression of type "cv void"
can be used only in functions with a return type of cv void;
the expression is evaluated just before the function returns
to its caller."

In case that's not clear 3.9.3p5 reads:
"In this International Standard, the notation cv (or cv1, cv2, etc.),
used in the description of types, represents an arbitrary set of
cv-qualifiers, i.e., one of {const}, {volatile}, {const, volatile},
or the empty set."

As you mentioned, despite the legality, it may not necessarily
be what you wanted, or it may be (this becomes more transparent
with templates).

 

[msalters]

First of all, there are *no* C++ compiler which comply fully
with the ANSI/ISO standards. The Comeau compilers come very close.
It is practically impossible for programmers to determine
for themselves whether any implementation complies or not.

In all honesty, when you get to the point where Comeau is, you
discover that the standard is slightly fuzzy. It's not unusual
for a Comeau user to discover that some obscure case in the
standard cannot be implemented. Just have a look at the Core DR
lists.

I *don't* trust the "regulars here".
The comp.lang.c++ newsgroup is *not* the most appropriate forum
to discuss the ANSI/ISO C++ standards or whether or not
any particular implementation complies.
The comp.std.c++ newsgroup is more appropriate.
The comp.std.c++ newsgroup attracts real experts
on the ANSI/ISO C++ standards so contributions
are more likely to be properly vetted.

Of course, the clc++m group attracts real experts as well. Reason
is simple, moderation keeps the traffic low enough. In fact, such
a trivial question would fit better here or in clc++m than in csc++

That's probably bad advice. The first problem is that
we have no way to determine who the "regulars" are
much less whether or not they have any credentials,
training or experience in C++ compiler implementation.
We have no way to determine whether their interpretations
of the ANSI/ISO standards are correct or not.

You don't have to implement a compiler to know one is wrong.
In fact, once you gain some experience, you'll learn what's
easy and what's impossible without implementing one. And
for 99% of the questions here, any interpretation backed by
a quote is correct simply because there is no misinterpretation
possible. The "expert" part is finding the right quote.
Regards,
Michiel Salters

 

[Richard Herring]

First of all, there are *no* C++ compiler which comply fully
with the ANSI/ISO standards.

Which rules out *your* suggestion above that the compiler is an
appropriate tool to test compliance.

The Comeau compilers come very close.
It is practically impossible for programmers to determine
for themselves whether any implementation complies or not.

In many cases, not all, it's trivial. Give it some test code, see
whether it compiles and how the compiled code behaves.

But you've digressed. The original question was about whether a piece of
*code* complied with the standard, not some compiler. Other posters
answered the question, complete with citations of the relevant portion
of the standard. If you don't trust them, you can read the standard for
yourself.

And many more who are not.
How to you tell the difference.

By reading their reasoned arguments? By reading the standard for
yourself? The question here was straightforward enough, and so directly
answered by the standard, that questions of "interpretation" just didn't
arise.

I *don't* trust the "regulars here".

Good advice, since you're one of them.

The comp.lang.c++ newsgroup is *not* the most appropriate forum
to discuss the ANSI/ISO C++ standards or whether or not
any particular implementation complies.
The comp.std.c++ newsgroup is more appropriate.

comp.std.c++ is the appropriate place for discussing the standard and
proposed changes to it. It's not necessarily the best place for
discussing compliance of some random compiler, still less some random
snippet of code.

The comp.std.c++ newsgroup attracts real experts
on the ANSI/ISO C++ standards so contributions
are more likely to be properly vetted.

Contributions making assertions about the standard, certainly.

That's probably bad advice. The first problem is that
we have no way to determine who the "regulars" are
much less whether or not they have any credentials,
training or experience in C++ compiler implementation.

And how is that any different for the "regulars" of comp.std.c++?

Some of the "regulars" here make testable claims. Some of them have
names and reputations outside this newsgroup. Some of them *are* the
"real experts" you think inhabit comp.std.c++.

We have no way to determine whether their interpretations
of the ANSI/ISO standards are correct or not.

We can read the standard for ourselves and follow their reasoned
arguments, can't we?

 

[Jerry Coffin]

msalters wrote:

[ ... ]

Of course, the clc++m group attracts real experts as well. Reason
is simple, moderation keeps the traffic low enough. In fact, such
a trivial question would fit better here or in clc++m than in csc++

clc++/clc++m have similar aims: discussion of the language as it stands
right now. csc++ has a completely different aim: to discuss the
standard for the language, how it should be changed, etc.

The difference here is not one of the level of expertise, but of
orientation. Most of the regulars in csc++ also participate on a
regular basis in clc++ and/or clc++m as well.

Google makes it easy to find regulars, but posting and dependability
are (unfortunately) more or less orthogonal.

Standard conformance is largely a question of facts (or lack thereof),
and is thus easier to evaluate on its own merits. The place you really
want to look for expertise is when somebody is giving advice about
programming technique. Here you're (largely) taking a guess at what's
likely to become useful in the future, so you're hoping that the
expert's experience will guide you into making decisions that turn out
well -- but knowing up front that no matter what you do, you're
basically playing the odds, with no facts about "right" or "wrong"
available until after the fact.

Even so, I, at least, believe that your judgement should be based more
on the qualities apparent in the arguments themselves than in the
reputation of the person who makes them. Just for one example, I can
remember the first few posts Andrei Alexandrescu made to comp.lang.c++:
he had virtually never posted anything, anywhere before, and I'd
certainly never heard of him before (this was well before he was
published). Dismissing him out of hand on that basis would have been a
_major_ mistake, at least IMO.

You don't have to implement a compiler to know one is wrong.
In fact, once you gain some experience, you'll learn what's
easy and what's impossible without implementing one. And
for 99% of the questions here, any interpretation backed by
a quote is correct simply because there is no misinterpretation
possible. The "expert" part is finding the right quote.

I'm not at all sure I'd agree with the 99% number, but there are
certainly quite a few questions for which the answers are sufficiently
well known that one quote from the correct part of the standrad
suffices as an answer.

A single quote will rarely suffice for an expert-level question though.
A difficult question might easily require bits and pieces from a half
dozen (often widely-separated) parts of the standard to resolve.

Worse, the standard is sufficiently large that when those half dozen
parts are combined, the result can be _most_ surprising to those who
think they know the standard the best (it certainly suprises me on a
regular basis).

 

[REH]

I think that's a pretty bad assessment. How can someone know if their
compiler is any good (compliant), if they don't themselves know what should
be correct? This newsgroup has some folks who are pretty darn good at
interpreting the standard doc's and presenting the OP with good responses.
Who would you trust, your VC++ 6.0 compiler, or one of the regulars here?
I'd listen to the regulars (and the FAQ), myself.

-some guy

That's quoted wrong. He wrote that crap, not me!

REH

 

[REH]

Notwithstanding that your foo above is defined incorrectly,

Yes, sorry, I was just trying too quickly to sketch an example of what I
wrote.

As you mentioned, despite the legality, it may not necessarily
be what you wanted, or it may be (this becomes more transparent
with templates).

Other than clarity or style/preferences (or the surprise!), is there a
reason why it's not what I wanted? I assume, from what I've been told, is
it's the same (functionally) as what I did want.

Thanks.

 

[Howard]

That's quoted wrong. He wrote that crap, not me!

REH

Sorry, I forgot to take out the line with "REH wrote:" when I snipped all
the stuff at the top.

-H

 

[E. Robert Tisdale]

We can read the standard for ourselves
and follow their reasoned arguments, can't we?

And, if we are ourselves infallible,
we can determine whether their interpretations
of the ANSI/ISO standards are correct or not.

According to the American Heritage Dictionary of the English Language

http://www.bartleby.com/61/

hubris
NOUN: Overbearing pride or presumption; arrogance:
“There is no safety in unlimited technological hubris”
(McGeorge Bundy).


I have observed that, when the same question is submitted
to both comp.lang.c++ and comp.std.c++ independently,
answers are challenged much more vigorously in comp.std.c++
The answers and challenges are much better and more reliable
in comp.std.c++
It appears that more experts on the ANSI/ISO C++ standards
subscribe and contribute to the comp.std.c++ newsgroup.

What I find most interesting is that many so-called experts
pronounced the original code snippet

void foo
{
}

void bar()
{
return foo();
}

submitted by REH "legal".
Evidently, none of them ever attempted to compile it.
In this case, *any* C++ compiler would have been
more reliable that the so-called experts.

If you have questions about whether a code is "legal" or not,
consult your C++ compiler first.
Consult the Comeau on-line C++ compiler
if you don't trust your compiler.
Consult the experts in the comp.std.c++ newsgroups
if doubt or suspicion remains.
The comp.lang.c++ newsgroup is just a good place to get bad advice
on "legal" issues concerning ANSI/ISO C++ standards.

 

[REH]

What I find most interesting is that many so-called experts
pronounced the original code snippet

void foo
{
}

void bar()
{
return foo();
}

submitted by REH "legal".
Evidently, none of them ever attempted to compile it.
In this case, *any* C++ compiler would have been
more reliable that the so-called experts.

I don't think they pronounced it legal or felt the need to compile it.
They, being smarter than a compiler, understand my mistake and intent, and
just answered my question. Sheesh, it was just an example to help convey
what I was trying to say.

 

[E. Robert Tisdale]

I don't think they pronounced it legal or felt the need to compile it.
They, being smarter than a compiler, understand my mistake and intent
and just answered my question.
Sheesh, it was just an example to help convey what I was trying to say.

Someday, we will have compilers that are that smart. ;-)
They will emit code code for the program that we should have written
instead of for the program that we actually wrote.
What will we need programmers for then?

 

[Noah Roberts]

First of all, there are *no* C++ compiler which comply fully
with the ANSI/ISO standards.

Ok, then I have a question. If there are no compliant C++
compilers,...why would I trust one to judge if my code is compliant?!
I'm confused.

 

[E. Robert Tisdale]

Ok, then I have a question.
If there are no compliant C++ compilers,
why would I trust one to judge if my code is compliant?

Because they are *more* reliable (trustworthy)
than contributers to the comp.lang.c++ newsgroup.
Compilers are written by professionals
who are much more expert in interpreting
the ANSI/ISO C++ standards
than the casual, pedestrian users
who contribute to the comp.lang.c++ newsgroup.