Topic: new/dynamic_cast/throw/return NULL
Author: news@news.demon.net ("News Admin")
Date: Wed, 30 Jun 2004 23:00:31 +0000 (UTC) Raw View
"Niklas Matthies" <usenet-nospam@nmhq.net> wrote in message
news:slrnce2v6b.1eha.usenet-nospam@nmhq.net...
> On 2004-06-28 18:48, Steve Clamage wrote:
>
> > - Exception handlers are rare compared to function definitions.
> > - Exceptions occur infrequently compared to function calls.
>
> This is what really restricts the use of exceptions in C++.
>
I think there are two, related, issues.
One is a philosophical/design issue about the proper place to use
exceptions.
The other is a pragmatic/implementation issue about the way exceptions
operate.
The approach the standards committee took to the first issue has meant that
most
implementations of C++ are optimised for the non-exception-throwing case,
and so attempting to use C++ exceptions for normal flow of control usually
has
measurably detrimental effects on performance.
Roger Orr
--
MVP in C++ at www.brainbench.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://www.jamesd.demon.co.uk/csc/faq.html ]
Author: francis@robinton.demon.co.uk (Francis Glassborow)
Date: Sat, 26 Jun 2004 07:04:40 +0000 (UTC) Raw View
In article <40dc39fa$0$25274$9b4e6d93@newsread2.arcor-online.net>,
edA-qa mort-ora-y <usenet@disemia.com> writes
>Though in general I agree there are some inconsistances with exception
>handling. It seems there are two general camps of people, who excert
>influence on the standard, in respect to exceptions:
> 1) Exceptions are truly that, things that don't happen often and
>are outside the normal processing stream
> 2) Exceptions are just another device for programming, nor more
>or less special than function return types
There are pitiful few of the second type if any in the Standard's world.
The designer of C++ together with many others have repeatedly pointed
out that exceptions are not designed as an alternative return path.
Attempts to use them as such are abuse of the mechanism.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ 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 ]
Author: usenet@disemia.com (edA-qa mort-ora-y)
Date: Sat, 26 Jun 2004 18:19:15 +0000 (UTC) Raw View
Francis Glassborow wrote:
>> 1) Exceptions are truly that, things that don't happen often and
>> are outside the normal processing stream
>> 2) Exceptions are just another device for programming, nor more
>> or less special than function return types
> There are pitiful few of the second type if any in the Standard's world.
> The designer of C++ together with many others have repeatedly pointed
> out that exceptions are not designed as an alternative return path.
> Attempts to use them as such are abuse of the mechanism.
I didn't mean to imply that they are used as return types, but I have a
hard time seeing as though they are anything other than an alternative
return path. Though this is not to imply that they are too be used for
normal return values.
That is, the first group (as I see it) tend to feel that exceptions
should only be used in abnormal cases of errors, and typically those
errors that may present a serious problem. And the second group tend to
express any conceiveable error condition, minor or otherwise, as a type
of exception and feel as though they should be thrown and caught frequently.
I find the standard to be overdone from the first respect, but underdone
in the second respect.
The ability to throw arbitrary objects is great, and the ability to
catch invalid exceptions, but missing is a good way to convert between
exceptions which have been thrown, there is no genuine alternate
processing path for thrown exceptions.
Thus the standard sits somewhere between the two ideas, and as such I'm
lead to believe there were people pulling it in both directions.
--
edA-qa mort-ora-y (Producer)
Trostlos Records <http://trostlos.org/>
"What suffering would man know if not for his own?"
---
[ 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 ]
Author: brangdon@cix.co.uk (Dave Harris)
Date: Sun, 27 Jun 2004 01:55:28 +0000 (UTC) Raw View
kprateek88@yahoo.com (Prateek R Karandikar) wrote (abridged):
> new was changed from returning NULL on failure to throwing an
> exception, even at the cost of breaking code. So there is a
> significant advantage in the latter approach.
Indeed. Recovering from out of memory probably means finding some spare
memory to free, aborting the current job and moving onto the next one, or
closing down altogether. These things are rarely the responsibility of the
direct caller of new. They need to be managed centrally. The failure needs
to be passed up the call tree to someone who can handle it. That is what
exceptions are good for.
> Why wasn't the same logic applied to dynamic_cast for pointers?
> Why doesn't it throw for failure?
Because here the direct caller often is best-placed to handle the failure.
It may be able to try a dynamic_cast to a different type, or just do
nothing. It would be annoying if we needed try/catch blocks for such
cases. Try/catch blocks should be rare.
> Why aren't pointers and references treated consistently?
One reason is that a pointer cast has a reasonable way to signify failure,
namely to return NULL, which is not available for references. References
cannot be NULL.
Another reason is that it's useful to have both kinds of error reporting
available. As with new and new(std::nothrow).
-- Dave Harris, Nottingham, UK
---
[ 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 ]
Author: Steve Clamage <stephen.clamage@sun.com>
Date: Mon, 28 Jun 2004 12:48:59 CST Raw View
edA-qa mort-ora-y wrote:
>
> That is, the first group (as I see it) tend to feel that exceptions
> should only be used in abnormal cases of errors, and typically those
> errors that may present a serious problem. And the second group tend to
> express any conceiveable error condition, minor or otherwise, as a type
> of exception and feel as though they should be thrown and caught
> frequently.
>
..
>
> Thus the standard sits somewhere between the two ideas, and as such I'm
> lead to believe there were people pulling it in both directions.
You really should have a look at "The Design and Evolution of C++",
which has a whole chapter on the design criteria for exceptions in
C++. It says in the introductory section:
"The following assumptions were made for the design:
- Exceptions are used primarily for error handling.
- Exception handlers are rare compared to function definitions.
- Exceptions occur infrequently compared to function calls.
..
What is meant is that exception handling
- Isn't intended simply as an alternative return mechanism ... but as
a mechanism for supporting fault-tolerant systems.
- Isn't intended to turn every function into a fault-tolerant entity..."
The definition of exceptions in the C++ standard are consistent with
these criteria and assumptions, and not at all consistent with the
idea of using exceptions for general flow control. Within the C++
committee, there was never any other viewpoint: exceptions are
expensive at run time and intended only for handling exceptional
(serious and rare) conditions. Nobody was pulling from the other
direction.
---
Steve Clamage, stephen.clamage@sun.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://www.jamesd.demon.co.uk/csc/faq.html ]
Author: usenet-nospam@nmhq.net (Niklas Matthies)
Date: Tue, 29 Jun 2004 14:51:15 +0000 (UTC) Raw View
On 2004-06-28 18:48, Steve Clamage wrote:
:
> You really should have a look at "The Design and Evolution of C++",
> which has a whole chapter on the design criteria for exceptions in
> C++. It says in the introductory section:
>
> "The following assumptions were made for the design:
> - Exceptions are used primarily for error handling.
This alone doesn't say much. One module's errors are another module's
well-defined evaluation results.
> - Exception handlers are rare compared to function definitions.
> - Exceptions occur infrequently compared to function calls.
This is what really restricts the use of exceptions in C++.
-- Niklas Matthies
---
[ 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 ]
Author: kprateek88@yahoo.com (Prateek R Karandikar)
Date: Fri, 25 Jun 2004 05:29:23 +0000 (UTC) Raw View
new was changed from returning NULL on failure to throwing an
exception, even at the cost of breaking code. So there is a
significant advantage in the latter approach. Why wasn't the same
logic applied to dynamic_cast for pointers? Why doesn't it throw for
failure? All the "infrastructure" for doing so is already in place:
dynamic_cast for references throws bad_cast to indicate failure. In
other words, there seems to be no fundamental problem in dynamic_cast
throwing (since the reference version throws). Why aren't pointers and
references treated consistently?
-- --
Abstraction is selective ignorance.
-Andrew Koenig
-- --
---
[ 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 ]
Author: francis@robinton.demon.co.uk (Francis Glassborow)
Date: Fri, 25 Jun 2004 14:54:28 +0000 (UTC) Raw View
In article <607f883e.0406241140.6fccb45c@posting.google.com>, Prateek R
Karandikar <kprateek88@yahoo.com> writes
>new was changed from returning NULL on failure to throwing an
>exception, even at the cost of breaking code. So there is a
>significant advantage in the latter approach. Why wasn't the same
>logic applied to dynamic_cast for pointers? Why doesn't it throw for
>failure? All the "infrastructure" for doing so is already in place:
>dynamic_cast for references throws bad_cast to indicate failure. In
>other words, there seems to be no fundamental problem in dynamic_cast
>throwing (since the reference version throws). Why aren't pointers and
>references treated consistently?
I think you have this one backwards.
It is rare that any form of the new expression fails and so handling
that via an exception rather than forcing good programmers to always
check return values is eminently sensible. OTOH it is actually normal
for a dynamic_cast<> to fail because we use it to check a condition of
which we are uncertain.
The problem is that we are cornered by the nature of references so that
they only option we have for applying a dynamic_cast<> to a reference is
to have it throw if it fails. In the case of pointers we can do better
and so we did so allowing such things as:
if(derived * handle = dynamic_cast<derived *> base_ptr){
// process
}
I do not think that I am alone in thinking that I would hate a
dynamic_cast<> that threw on failure (I actually very rarely use a
dynamic_cast for a reference).
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
---
[ 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 ]
Author: dsp@bdal.de (=?ISO-8859-1?Q?=22Daniel_Kr=FCgler_=28ne_Spangenberg=29=22?=)
Date: Fri, 25 Jun 2004 17:51:11 +0000 (UTC) Raw View
Good morning Prateek R Karandikar,
Prateek R Karandikar schrieb:
>new was changed from returning NULL on failure to throwing an
>exception, even at the cost of breaking code. So there is a
>significant advantage in the latter approach. Why wasn't the same
>logic applied to dynamic_cast for pointers? Why doesn't it throw for
>failure? All the "infrastructure" for doing so is already in place:
>dynamic_cast for references throws bad_cast to indicate failure. In
>other words, there seems to be no fundamental problem in dynamic_cast
>throwing (since the reference version throws). Why aren't pointers and
>references treated consistently?
>
>-- --
>Abstraction is selective ignorance.
>-Andrew Koenig
>-- --
> =20
>
One note before answering your actual reason of posting: Your final=20
quote combined with your
missing signature leads to the unfortune impressionm, that this=20
contribution came from Andrew Koenig
himself.
I can't say much concerning the historical evolution of new concerning=20
throwing an exception
versus returning 0, but to my opinion the two aspects of dynamic_cast=20
are actually a Good Thing,
because (similar to new (no_throw)) you **have** the possibility to go=20
the exception-free route,
if you want. This allows programming techniques similar to the following:
struct clonable { virtual ~clonable(); ... };
struct drawable : clonable { ... };
..
void foo(const clonable& item)
{
if (dynamic_cast<const drawable*>(&item)) {
// do some drawing stuff
...
}
...
}
which should of course, not be abused in the sense of dynamic switches...
Thus you have a similar tool compared to the two counter parts=20
has_facet<> and use_facet<> from
<locale>. Now one could have considered a replacement of dynamic_cast by=20
similar functions
is_dynamic_type<>/use_dynamic_type<>, but the current absence of those=20
signatures is part of the
historical evolution of the standard, I assume.
Greetings from Bremen,
Daniel Kr=FCgler
---
[ 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 ]
Author: Michiel.Salters@logicacmg.com (Michiel Salters)
Date: Fri, 25 Jun 2004 17:51:17 +0000 (UTC) Raw View
kprateek88@yahoo.com (Prateek R Karandikar) wrote in message news:<607f883e.0406241140.6fccb45c@posting.google.com>...
> new was changed from returning NULL on failure to throwing an
> exception, even at the cost of breaking code. So there is a
> significant advantage in the latter approach.
Yes, out of memory is exceptional enough to not deal with it everywhere.
In addition, the exact allocation usually doesn't matter. I don't care
whether the Name string or the Address string in my Person object was
the one to run out of memory.
> Why wasn't the same
> logic applied to dynamic_cast for pointers? Why doesn't it throw for
> failure? All the "infrastructure" for doing so is already in place:
> dynamic_cast for references throws bad_cast to indicate failure. In
> other words, there seems to be no fundamental problem in dynamic_cast
> throwing (since the reference version throws). Why aren't pointers and
> references treated consistently?
Because sometimes, a dynamic_cast returning 0 is expected. The price
for exceptions would be rather high there. In addition, it turns out
that the 0-return isquite useful to fold the no-input and
wrong-type-input:
void foo( Object* o )
{
if( MyObj* myobj = dynamic_cast<MyObj*>( o ) )
{
// I got an MyObj
}
}
Regards,
Michiel Salters
---
[ 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 ]
Author: usenet@disemia.com (edA-qa mort-ora-y)
Date: Fri, 25 Jun 2004 19:38:51 +0000 (UTC) Raw View
Prateek R Karandikar wrote:
> failure? All the "infrastructure" for doing so is already in place:
> dynamic_cast for references throws bad_cast to indicate failure. In
> other words, there seems to be no fundamental problem in dynamic_cast
> throwing (since the reference version throws). Why aren't pointers and
> references treated consistently?
I kind of understood that new throws an exception since in normal
circumstances you'd expect the function to be successful, thus this
saves a lot of "if( p = 0 ) ..." checks in the default code.
Whereas dynamic_cast works both as a casting operator and as the Java
"instanceof" operator. If you want a reference then there is no way to
return null, since you couldn't check the the return type. But for a
pointer you can, thus this works as a quick way to see if the type is
castable to another type or not (without having to do exception code --
which is a annoying to try and embed in an if/then statement).
Though in general I agree there are some inconsistances with exception
handling. It seems there are two general camps of people, who excert
influence on the standard, in respect to exceptions:
1) Exceptions are truly that, things that don't happen often and are
outside the normal processing stream
2) Exceptions are just another device for programming, nor more or less
special than function return types
--
edA-qa mort-ora-y (Producer)
Trostlos Records <http://trostlos.org/>
"What suffering would man know if not for his own?"
---
[ 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 ]