John Aldridge wrote:
> >>>>>>> John Aldridge <jpsa@apollo.uk.gdscorp.com> writes
>
>    :
>    virtual int fred (void) { throw "Wrong type"; }
>    :
>
> >>> HP's response to my logging this as a fault was:
> >>
> >>>> In C++, the absence of a return value from a function that is
> >>>> declared to return a value is a compile time error; see 6.6.3 in
> >>>> the ARM.  (In ANSI C, this behavior is undefined.)
> >>
> >>> Are they right?

One point I have not yet seen raised in this discussion is whether it is
incorrect to declare the function as returning an int when in fact it is
known to never return; that may be the basis of HP's decision to reject the
example.  However, the function may be forced to match a particular
signature, particularly if invoked through a member pointer or other function
pointer.

Still, it is at least good practice to put in a return statement for the
correct type even if the return point is unreachable, to defend against
later changes to the function if nothing else.

However, I don't know if I can really agree with the compiler's refusal to
generate code over it.  It's a rather picky point for such a drastic response,
and even if it may be questionable judgement, it is not necessarily a coding
defect.

--
I protest!  I am *NOT* a Merry Man!
Dave Toland       Platinum Solutions, Inc.    det@platsol.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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4nva9m$72o@engnews1.Eng.Sun.COM> Dave Toland
<det@platsol.com> writes:

|> John Aldridge wrote:
|> > >>>>>>> John Aldridge <jpsa@apollo.uk.gdscorp.com> writes
|> >
|> >    :
|> >    virtual int fred (void) { throw "Wrong type"; }
|> >    :
|> >
|> > >>> HP's response to my logging this as a fault was:
|> > >>
|> > >>>> In C++, the absence of a return value from a function that is
|> > >>>> declared to return a value is a compile time error; see 6.6.3 in
|> > >>>> the ARM.  (In ANSI C, this behavior is undefined.)
|> > >>
|> > >>> Are they right?

|> One point I have not yet seen raised in this discussion is whether it is
|> incorrect to declare the function as returning an int when in fact it is
|> known to never return; that may be the basis of HP's decision to reject
|> the example.  However, the function may be forced to match a particular
|> signature, particularly if invoked through a member pointer or other
|> function pointer.

The case typically comes up in class hierarchies.  Given that some of
the derived classes will support frumigating, it is not rare for the
base class to contain something like the following:

 virtual bool frumigatingSupported() const
  { return false ; }
 virtual int  frumigateAway()
  { assert( 0 ) ; }

If frumigating requires returning an int, then the signature in the
base class must return an int (although the function never returns).

|> Still, it is at least good practice to put in a return statement for the
|> correct type even if the return point is unreachable, to defend against
|> later changes to the function if nothing else.

Easier said than done.  Suppose the return value is a class type which
has no default constructor.

|> However, I don't know if I can really agree with the compiler's refusal to
|> generate code over it.  It's a rather picky point for such a drastic
|> response, and even if it may be questionable judgement, it is not
|> necessarily a coding defect.

I think that the standard requires the compiler to generate code.
 [Moderator's note: yes, James Kanze is right, it does.
  There is really no doubt about this!  -fjh.]

James Kanze US/ESC 60/3/141 #40763 wrote:
> From a quality of implementation point of view, I would be very
> disappointed in a compiler that warned in such cases if the immediately
> preceding statement was throw, exit, abort, ...  These are all things
> the compiler can (and should) know about.

I would forgive them if it was abort(), since they have to provide the
library function, but you can have your own abort linked in that does
something else ... like abort a database transaction.

not that one SHOULD ...

 [Moderator's note: no, the draft standard does not allow to define
 your own abort() function.  If you do so, the behaviour is undefined.
 (Of course it make happen to work on particular implementations.)
 The only standard library functions which portable C++ programs can
 replace are the various operator new and delete functions. -fjh.]

--
#include <legalbs/standarddisclaimer>
Rich Paul                |  If you like what I say, tell my
C++, OOD, OOA, OOP,      |  employer, but if you don't,
OOPs, I forgot one ...   |  don't blame them.  ;->
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]