Francis Glassborow wrote:
>
> Which leads to the silly coding style of always ending a function with a
> return statement to keep the compiler happy even though you know that it
> will never be executed.
>

Silly or defensive?  What if somting changes that does result in a return?

Ian

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kanze wrote:
>
>  > and this could be wrapped up in a suitably-named template or macro:
>
>  >     return unreachable_value<MyType>();
>
>  > or whatever.  I'd have thought this would only fail if the type
>  > has no accessible copy-constructor, in which case we shouldn't
>  > be returning it in the first place.
>
> On the other hand... if we're going to start down this road,
> let's do it right.  Introduce some means of saying that a
> function never returns, for example -- maybe a return type of
> "void void".  I think that with very, very few additions, we
> could reach a point where the compiler could decide, at least in
> almost all reasonable cases.  Of course, there is the problem of
> backwards compatible -- my "fatalError" function doesn't return
> "void void" at present.
>
Would it not be better to stick with the template unreachable_value and
let the compiler deduce the type, which should be a trivial operation?

Ian


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze wrote:
>
> I don't think you really understood my objections to fixing it.
> I'm all in favor of a maximum of safety.  But the difference
> here with Java is notable: in Java, you can only return a
> pointer or a built in type, so in every case, there is a trival
> default that you can use, even if you know that you will never
> get there.  In C++, you can return complex value types, and
> there are cases where there is no reasonable default available,
> even if you know that it will never be used.  To introduce a
> requirement here would either require the compiler to be able to
> do all of the necessary analysis (which in turn means
> cross-module flow analysis), or to ban returning values, at
> least of user defined types.  Not only would this break almost
> all existing applications, it would introduce any number of
> lifetime of object issues.  IMHO, the ability to return values
> is more important than catching the few errors which result from
> this not being controlled.
>
Going off on a bit of a tangent, but isn't the existence of functions
that might not return what they say they will a code smell?

All I was asking for was a diagnostic or error if each branch within a
function didn't return the correct type.  Whether or not a function
throws an exception isn't relevant.

Ian

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Maciej Sobczak wrote:
>
> In general, flowing off the end cannot be reliably detected at compile
> time due to exceptions that can prevent the control from flowing off the
> end:
>
> int foo()
> {
>     bar();
> } // flowing off the end? no, if bar throws
>
This is obviously making no attempt to return something.  It should be
possible to detect the absence of any return statement, or a void return
in a value returning function.

I think Sun CC has it right:

int foo() { return 0; }

int bar() { foo(); }

int bwibble( int n )
{
   switch( n )
   {
     case 1:  return;
     case 2:  return 1;
     default: break;
   }
}

CC /tmp/x.cc
"/tmp/x.cc", line 3: Error: "bar()" is expected to return a value.
"/tmp/x.cc", line 9: Error: "bwibble(int)" is expected to return a value.
"/tmp/x.cc", line 10: Warning: There are returns from bwibble(int) with
and without values.

Ian


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>>
>> Should this undefined behaviour be promoted to a compile time error?
>
>    Of course it should be an error.
>
>    But it won't be changed.  That would break existing code.
>
Break existing broken code, interesting concept!

Ian

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kuyper@wizard.net wrote:
> If the diagnostic is only an option, and not
> mandatory, then "undefined behavior" already covers that. One of the
> permissible forms of undefined behavior, if it can be proven at compile
> time that having undefined behavior is an unavoidable consequence of
> running the program, is to refuse to compile the code, with a
> diagnostic.
>
Thanks for that clarification, I think that answers my point.

Cheers,

Ian

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]