James Kuyper wrote:
>
> You find "while(true)" less cryptic than "for(;;)"? I find any notation
> that implies that the loop never terminates excessively cryptic, unless
> it does in fact never terminate. Most real-life loops do terminate, and
> I
> feel that the main loop-exit condition should be part of the loop
> control structure; having to search for it elsewhere is unnecessarily
> confusing. I don't mind placing additional break; return; throw(),
> exit(),
> or abort() statements inside the loop if appropriate, but the main or
> default exit should be through the loop condition itself. Just my
> opinion.

What if the loop's natural terminating condition occurs partway through,
and there's no reason to apply any test at the beginning/end of the
loop? I frequently write input loops like this:

    std::string line;
    for (;;) {
      std::getline(std::cin, line);
      if (std::cin.eof())
        break;
      if (!std::cin)
        throw ReadError();
      // ... do something with line ...
    }

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
"C++ is to programming as sex is to reproduction. Better ways might
technically exist but they're not nearly as much fun." -- Nikolai Irgens

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ross Smith wrote:
>
> James Kuyper wrote:
> >
> > You find "while(true)" less cryptic than "for(;;)"? I find any notation
> > that implies that the loop never terminates excessively cryptic, unless
> > it does in fact never terminate. Most real-life loops do terminate, and
> > I
> > feel that the main loop-exit condition should be part of the loop
> > control structure; having to search for it elsewhere is unnecessarily
> > confusing. I don't mind placing additional break; return; throw(),
> > exit(),
> > or abort() statements inside the loop if appropriate, but the main or
> > default exit should be through the loop condition itself. Just my
> > opinion.
>
> What if the loop's natural terminating condition occurs partway through,
> and there's no reason to apply any test at the beginning/end of the
> loop? I frequently write input loops like this:
>
>     std::string line;
>     for (;;) {
>       std::getline(std::cin, line);
>       if (std::cin.eof())
>         break;
>       if (!std::cin)
>         throw ReadError();
>       // ... do something with line ...
>     }

For code like that, I tend to put the action preceding the test inline
with the test, as follows:

for(std::string line;
 !std::getline(std::cin, line).eof(); )
{
       if (!std::cin)
         throw ReadError();
       // ... do something with line ...
}

The advantage of this version is that the loop constructs themselves
tell you that you're looping until you reach the end of the file. Your
version buries that fact inside the body of the loop. I'll grant you, in
this loop that's not a very deep burial, but it's still less clear to me
than my re-write. YMMV.

Moving the 'line' definition inside the for() is optional, and can't be
done if any code after the loop uses 'line'. However, for code like
this, it's often (but not necessarily) bad design to use the input
buffer outside of the loop.


======================================= MODERATOR'S COMMENT:
 This thread is straying into comp.lang.c++.* territory; please keep any followups on topic for comp.std.c++.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ross Smith wrote:
>> What if the loop's natural terminating condition occurs partway
>> through, and there's no reason to apply any test at the
>> beginning/end of the loop? I frequently write input loops like this:
>>
>>     std::string line;
>>     for (;;) {
>>       std::getline(std::cin, line);
>>       if (std::cin.eof())
>>         break;
>>       if (!std::cin)
>>         throw ReadError();
>>       // ... do something with line ...
>>     }

James Kuyper wrote:
> For code like that, I tend to put the action preceding the test inline
> with the test, as follows:
>
> for(std::string line;
>         !std::getline(std::cin, line).eof(); )
> {
>        if (!std::cin)
>          throw ReadError();
>        // ... do something with line ...
> }
>
> The advantage of this version is that the loop constructs themselves
> tell you that you're looping until you reach the end of the file. Your
> version buries that fact inside the body of the loop.

And you're burying a variable definition inside a looping construct.
Why not write this as:

    std::string  line;

    while (not std::getline(std::cin, line).eof())
    {
        if (not std::cin)
            throw ReadError();

        // ... do something with line ...
    }

I prefer to separate variable definitions and control statements.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Xazziri wrote:
>
> "David R Tribble" <david@tribble.com> wrote in message
> news:39918A31.8F50684D@tribble.com...
> <snip>
> > Anyway, I prefer to use
> >     for (;;)
> > over
> >     while (true)
> > since it's generally accepted as *the* C idiom for "infinite loop"
> > (see K&R2e, 3.5).
> >
> Naah. Admit it. You're only using that because it looks cool. Who would want
> to write something obvious like 'while(true)' when you can do it the
> classic, cryptic C way with 'for (;;)'? HHOS, of course...

You find "while(true)" less cryptic than "for(;;)"? I find any notation
that implies that the loop never terminates excessively cryptic, unless
it does in fact never terminate. Most real-life loops do terminate, and
I
feel that the main loop-exit condition should be part of the loop
control structure; having to search for it elsewhere is unnecessarily
confusing. I don't mind placing additional break; return; throw(),
exit(),
or abort() statements inside the loop if appropriate, but the main or
default exit should be through the loop condition itself. Just my
opinion.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"David R Tribble" <david@tribble.com> wrote in message
news:39918A31.8F50684D@tribble.com...
<snip>
> Anyway, I prefer to use
>     for (;;)
> over
>     while (true)
> since it's generally accepted as *the* C idiom for "infinite loop"
> (see K&R2e, 3.5).
>
Naah. Admit it. You're only using that because it looks cool. Who would want
to write something obvious like 'while(true)' when you can do it the
classic, cryptic C way with 'for (;;)'? HHOS, of course...

X.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8mtmu7$t1h$1@nereid.worldonline.nl>,
Xazziri <xazziri@gmx.net> wrote:
>"David R Tribble" <david@tribble.com> wrote in message
>news:39918A31.8F50684D@tribble.com...
><snip>
>> Anyway, I prefer to use
>>     for (;;)
>> over
>>     while (true)
>> since it's generally accepted as *the* C idiom for "infinite loop"
>> (see K&R2e, 3.5).
>
>Naah. Admit it. You're only using that because it looks cool. Who would want
>to write something obvious like 'while(true)' when you can do it the
>classic, cryptic C way with 'for (;;)'? HHOS, of course...

You'd be surprised how many people don't know what while(true) means either
and/or couldn't think of it themselves and/or just use it because they
were told to.  Obvious?  Beauty is in the eye or the beholder.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell wrote:
>> int MyFunc()
>> {
>>     while (true)
>>     {
>>         for (int i=0;i<1000;i++)
>>         {
>>             if (array[i]) return array[i];
>>         }
>>         // Now do something else
>>     }
>> }
>>
>> This return statement is the only return statement.  It is the only
>> way that my function will return.  [...]
>> Does the standard require a terminating return statement?

James Kuyper wrote:
> But there's nothing in the C standard that requires a function to ever
> return. I don't approve of while(true) in general, but it is a common
> idiom, and could be used to implement a program that is supposed to
> wait indefinitely until it's condition is met.

Perhaps he's coding a multithreaded program, where the main thread
loops forever waiting for events which it then dispatches to other
threads.  Or perhaps he's writing embedded code for a device that in
theory never stops running; he did say he was short on code space,
implying that it's a small program running on an embedded system.
There are plenty of examples demonstrating that infinite loops are
appropriate in many coding situations.

Anyway, I prefer to use
    for (;;)
over
    while (true)
since it's generally accepted as *the* C idiom for "infinite loop"
(see K&R2e, 3.5).

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi all,

If I declare a function to return a value, such as :

int MyFunc();

it's possible to code it in such a way that the closing curly brace will
never be reached, such as this that I coded:

int MyFunc()
{
 while (true)
 {
  for (int i=0;i<1000;i++)
  {
   if (array[i]) return array[i];
  }
 // Now do something else
 }
}

This return statement is the only return statement.  It is the only way
that my function will return.

My compiler (Visual C++) chucks a wobbly and says that not all control
pathways return a value.  This ain't true.  Is my code non-standard?  Does
the standard require a terminating return statement?

I also frequently come across this type of thing:

int MyFunc2(int input)
{
  switch (input)
 {
 case -1: return 0;
 case 0: return -1;
 case 1: return 1;
 }
 return 0; // This cannot execute
}

and I happen to know that the input will only ever be -1, 0, or 1.  Now my
compiler requires the last 'return' statement, and it is just taking up
run-time space.  It is critical to me that I eliminate unnecessary bytes
of code on this project.

Is the last function non-standard without the last return?

--------------
Richard Cavell
Melbourne University Medical Student, Debater, Chess Player, etc.
- r.cavell@ugrad.unimelb.edu.au

Celebrating the Micro$oft breakup.
Newsgroups - Please keep it on the group, and copy your replies to me via
email. (Server problems).


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Pine.OSF.4.10.10008062347520.31540-100000@cassius.its.unimelb.edu.au>,
Richard John Cavell  <rjcavell@student.unimelb.edu.au> wrote:
>it's possible to code it in such a way that the closing curly brace will
>never be reached, such as this that I coded:
>
>int MyFunc()
>{
> while (true)
> {
>  for (int i=0;i<1000;i++)
>  {
>   if (array[i]) return array[i];
>  }
> // Now do something else
> }
>}
>
>This return statement is the only return statement.  It is the only way
>that my function will return.
>
>My compiler (Visual C++) chucks a wobbly and says that not all control
>pathways return a value.  This ain't true.  Is my code non-standard?  Does
>the standard require a terminating return statement?

Functions which are declared to return values are expected to
have respective return statements in all paths leading out of
the function.  If not, it's undefined behavior.

That said, clearly if you add a (bogus) return between the
two squigly braces, I would expect one to get an warning along
the line of "statement is unreachable".

So perhaps what this comes down to is whether the compiler
is required to evaluate the while expression to see if it is
a constant value such as true?

Answering that may seem like it comes down to a QoI issue,
but the Standard also has the notion of the "as if" rule,
which tells us that if the compiler has observed something that
it sees has no side-effect, etc, then it can ignore constraints
imposed by the Standard so long as it's _as if_ the constraint
was followed.

So strictly speaking, the function is missing a return.
However, if a compiler can see that the while always loops,
then I think the as if rule allows it to not require it,
and to do so safely.

So, in conclusion, I guess that your code is non-standard,
but not something to worry about.

>I also frequently come across this type of thing:
>
>int MyFunc2(int input)
>{
>  switch (input)
> {
> case -1: return 0;
> case 0: return -1;
> case 1: return 1;
> }
> return 0; // This cannot execute
>}
>
>and I happen to know that the input will only ever be -1, 0, or 1.  Now my
>compiler requires the last 'return' statement, and it is just taking up
>run-time space.  It is critical to me that I eliminate unnecessary bytes
>of code on this project.
>
>Is the last function non-standard without the last return?

This sounds way too low-level a concern, but then again,
I realize that some apps do need to worry about stuff like this.
Anyway, perhaps you wanna:

....
default:
case -1: return 0;
....

which will cover all paths into the switch, and so therefore
all paths out of the function as well.  There's probably
some cute alternative algorithm to the above too.

- Greg
--
Comeau Computing / Comeau C/C++ 4.2.42 (4.2.44 expected soon)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Richard John Cavell" <rjcavell@student.unimelb.edu.au> wrote...
> Hi all,
>
> If I declare a function to return a value, such as :
>
> int MyFunc();
>
> it's possible to code it in such a way that the closing curly brace will
> never be reached, such as this that I coded:
>
> int MyFunc()
> {
> while (true)
> {
> for (int i=0;i<1000;i++)
> {
> if (array[i]) return array[i];
> }
> // Now do something else
> }
> }
>
> This return statement is the only return statement.  It is the only way
> that my function will return.
>
> My compiler (Visual C++) chucks a wobbly and says that not all control
> pathways return a value.  This ain't true.  Is my code non-standard?  Does
> the standard require a terminating return statement?

I know, the result of a compiler work is not really a proof, yet
when *my* copy of Visual C++ compiles the following, I get *no*
compiler diagnostic whatsoever.

int array[1000];

int MyFunc()
{
    while (true)
    {
        for (int i=0;i<1000;i++)
        {
            if (array[i]) return array[i];
        }
        // Now do something else
    }
}

int main()
{
    return MyFunc();
}

Could it be you need to upgrade your compiler?

>
> I also frequently come across this type of thing:
>
> int MyFunc2(int input)
> {
>   switch (input)
> {
> case -1: return 0;
> case 0: return -1;
> case 1: return 1;
> }
> return 0; // This cannot execute
> }
>
> and I happen to know that the input will only ever be -1, 0, or 1.  Now my
> compiler requires the last 'return' statement, and it is just taking up
> run-time space.  It is critical to me that I eliminate unnecessary bytes
> of code on this project.

Well, _you_ know it will only be -1, 0, or 1.  How does your compiler
know that?  Did you tell it?  The other way to write your code would
be:

if (input < 0) // case -1:
    return 0;
else if (0 == input) // case 0:
    return -1;
else   //  case 1:
    return 1;

You compiler shouldn't complain here.

>
> Is the last function non-standard without the last return?

Standard, 6.6.3 The return statement, end of paragraph 2:
"Flowing off the end of a function is equivalent to a return
 with no value; this results in undefined behavior in a
 value-returning function."

Standard, 1.3.12 undefined behavior
"behavior, such as might arise upon use of an erroneous program
 construct or erroneous data, for which this International Standard
 imposes no requirements. Undefined behavior may also be expected
 when this International Standard omits the description of any
 explicit definition of behavior. [Note: permissible undefined behavior
 ranges from ignoring the situation completely with unpredictable
 results, to behaving during translation or program execution in a
 documented manner characteristic of the environment (with or without
 the issuance of a diagnostic message), to terminating a translation
 or execution (with the issuance of a diagnostic message). Many
 erroneous program constructs do not engender undefined behavior;
 they are required to be diagnosed. ]"

Especially, see the Note.  Your compiler is not required to give
any diagnostic.

Victor
--
Please remove capital A's from my address when replying by mail



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi!

Others have pointed out, why case two needs the return statement (I'd go
for the default alternative), but they failed to explain why case one
needs it.

Richard John Cavell wrote:
>
> Hi all,
>
> If I declare a function to return a value, such as :
>
> int MyFunc();
>
> it's possible to code it in such a way that the closing curly brace will
> never be reached, such as this that I coded:
>
> int MyFunc()
> {
>         while (true)
>         {
>                 for (int i=0;i<1000;i++)
>                 {
>                         if (array[i]) return array[i];
>                 }
>         // Now do something else
>         }
> }
>
> This return statement is the only return statement.  It is the only way
> that my function will return.
>
> My compiler (Visual C++) chucks a wobbly and says that not all control
> pathways return a value.  This ain't true.  Is my code non-standard?  Does
> the standard require a terminating return statement?

Consider the if! How should the compiler know (without analyzing all
possible data for array) whether the condition ever evaluates to true.
As long as there is the possibility that array[i] never evaluates to
true, no return will be called.

[snipped case 2]

hth,
Heinz

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell wrote:
>
> Hi all,
>
> If I declare a function to return a value, such as :
>
> int MyFunc();
>
> it's possible to code it in such a way that the closing curly brace will
> never be reached, such as this that I coded:
>
> int MyFunc()
> {
>         while (true)
>         {
>                 for (int i=0;i<1000;i++)
>                 {
>                         if (array[i]) return array[i];
>                 }
>         // Now do something else
>         }
> }
>
> This return statement is the only return statement.  It is the only way
> that my function will return.
>
> My compiler (Visual C++) chucks a wobbly and says that not all control
> pathways return a value.  This ain't true.  Is my code non-standard?  Does
> the standard require a terminating return statement?

I hope you'll find that that's only a warning message, not something
that prevents compilation. Reaching the end of a function that has a
non-void return type without issuing a return statement with a value,
results in undefined behavior. However, you don't do that, so they have
no justification for rejecting your code.

Your compiler can warn you about anything it wants to, and this is a
very good thing for them to warn about. "while(true)" is usually a
strong indication of poor design.

> I also frequently come across this type of thing:
>
> int MyFunc2(int input)
> {
>   switch (input)
>         {
>         case -1: return 0;
>         case 0: return -1;
>         case 1: return 1;
>         }
>         return 0;       // This cannot execute
> }
>
> and I happen to know that the input will only ever be -1, 0, or 1.  Now my
> compiler requires the last 'return' statement, and it is just taking up
> run-time space.  It is critical to me that I eliminate unnecessary bytes
> of code on this project.

A few extra bytes of code matter that much to you, and you're using C++?
If memory is that tight, you should be using assembler, not C++.

For almost any project where C++ is more appropriate than assembler, I'd
recommend adding a 'default:' case to your switch statement, and adding
some error handling code for that case. You wouldn't get code like that
past a code review at my shop. If you put the function in the unnamed
namespace, then every use of it would have to be traceable back to the
same translation unit. Each of those uses could then be checked to
verify that they didn't pass invalid arguments to MyFunc2, in which case
it might be allowed, but otherwise it's just too dangerous.

> Is the last function non-standard without the last return?

I don't believe so.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In the first case, the compiler might be able to figure out logically that
your return can be the only way out of the function. In the second case it is
impossible for the compiler to know that -1,0,1 are the only valid values. As
to what the standard says about this, hopefully someone else will enlighten
us. Normally if the my compiler does not find a return statement in all
possible paths it issues a warning but not an error, leading me to believe
that the standard does not mandate a return in all possible paths.

Richard John Cavell wrote:

> int MyFunc()
> {
>         while (true)
>         {
>                 for (int i=0;i<1000;i++)
>                 {
>                         if (array[i]) return array[i];
>                 }
>         // Now do something else
>         }
> }
>
> This return statement is the only return statement.  It is the only way
> that my function will return.
>
> My compiler (Visual C++) chucks a wobbly and says that not all control
> pathways return a value.  This ain't true.  Is my code non-standard?  Does
> the standard require a terminating return statement?
>
> I also frequently come across this type of thing:
>
> int MyFunc2(int input)
> {
>   switch (input)
>         {
>         case -1: return 0;
>         case 0: return -1;
>         case 1: return 1;
>         }
>         return 0;       // This cannot execute
> }
>
> and I happen to know that the input will only ever be -1, 0, or 1.  Now my
> compiler requires the last 'return' statement, and it is just taking up
> run-time space.  It is critical to me that I eliminate unnecessary bytes
> of code on this project.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <398E87DE.D1DA3F00@elbanet.co.at>,
Heinz Huber  <Heinz.Huber@elbanet.co.at> wrote:
>Hi!
>
>Others have pointed out, why case two needs the return statement (I'd go
>for the default alternative), but they failed to explain why case one
>needs it.
>
>Richard John Cavell wrote:
>>
>> Hi all,
>>
>> If I declare a function to return a value, such as :
>>
>> int MyFunc();
>>
>> it's possible to code it in such a way that the closing curly brace will
>> never be reached, such as this that I coded:
>>
>> int MyFunc()
>> {
>>         while (true)
>>         {
>>                 for (int i=0;i<1000;i++)
>>                 {
>>                         if (array[i]) return array[i];
>>                 }
>>         // Now do something else
>>         }
>> }
>>
>> This return statement is the only return statement.  It is the only way
>> that my function will return.
>>
>> My compiler (Visual C++) chucks a wobbly and says that not all control
>> pathways return a value.  This ain't true.  Is my code non-standard?  Does
>> the standard require a terminating return statement?
>
>Consider the if! How should the compiler know (without analyzing all
>possible data for array) whether the condition ever evaluates to true.
>As long as there is the possibility that array[i] never evaluates to
>true, no return will be called.

The important feature of the above code is the infinite while(true) loop.
The if-statement is a red herring that the OP put in just to show that his
function *could* return.

This whole issue is a QoI thing.  A compiler *must* compile the above code
successfully.  But compilers are permitted to *warn* about anything they
want, and they needn't perform a deep semantic analysis to determine
whether a warning is justified.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Heinz Huber wrote:
>
> Hi!
>
> Others have pointed out, why case two needs the return statement (I'd go
> for the default alternative), but they failed to explain why case one
> needs it.

That's because it doesn't.

> Richard John Cavell wrote:
> >
> > Hi all,
> >
> > If I declare a function to return a value, such as :
> >
> > int MyFunc();
> >
> > it's possible to code it in such a way that the closing curly brace will
> > never be reached, such as this that I coded:
> >
> > int MyFunc()
> > {
> >         while (true)
> >         {
> >                 for (int i=0;i<1000;i++)
> >                 {
> >                         if (array[i]) return array[i];
> >                 }
> >         // Now do something else
> >         }
> > }
> >
> > This return statement is the only return statement.  It is the only way
> > that my function will return.
> >
> > My compiler (Visual C++) chucks a wobbly and says that not all control
> > pathways return a value.  This ain't true.  Is my code non-standard?  Does
> > the standard require a terminating return statement?
>
> Consider the if! How should the compiler know (without analyzing all
> possible data for array) whether the condition ever evaluates to true.
> As long as there is the possibility that array[i] never evaluates to
> true, no return will be called.

But there's nothing in the C standard that requires a function to ever
return. I don't approve of while(true) in general, but it is a common
idiom, and could be used to implement a program that is supposed to wait
indefinitely until it's condition is met. In this case, perhaps array is
a pointer to volatile memory that is mapped to an external data source.
The program is waiting for it to be filled in by that source.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]