------=_Part_345_16143555.1354444175001
Content-Type: text/plain; charset=ISO-8859-1

Since c++ has exception handling mechanism and the inventor of c++ is also
inventor of some programming paradigms (i.e. RAII) relying on exceptions
and stack unwinding, why doesn't c++ has standard way of handling such
events as exceptions but as abnormal program termination instead?
For example, if I try to dereference an invalid pointer system is supposed
to send a segmentation fault message and leading to program
termination.Smart pointers has this problem too because even when you
dereference a smart pointer this can still happen. (I guess that is why
even garbage collecting languages such as c# or java has their invalid
pointer exceptions).

I could have found only one item about this in c++ standard document and it
is like this: "The effect of using an invalid pointer value (including
passing it to a deallocation function) is undefined." this was under
"basic.stc.dynamic.deallocation". As a result such a catastrophic event is
handled differently by different compilers and platforms. It is not even
calling terminate on my VS2012. I see my stack unwinding being done
properly only if I use /EHa switch which is said to end in slower and
bigger code in x86 and bigger code in x64<http://stackoverflow.com/questions/4573536/ehsc-vc-eha-synchronous-vs-asynchronous-exception-handling>
..

What I am trying to say is C had its way of handling such events via
signals. Why doesn't C++ has its way of defining those things as exceptions
or with something like terminate? If not please define something more
appropriate than RAII for resource handling, because stack unwinding
calling destructors looks like a lie this way.

--




------=_Part_345_16143555.1354444175001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Since c++ has exception handling mechanism and the inventor of c++ is also =
inventor of some programming paradigms (i.e. RAII) relying on exceptions an=
d stack unwinding, why doesn't c++ has standard way of handling such events=
 as exceptions but as abnormal program termination instead?<div>For example=
, if I try to dereference an invalid pointer system is supposed to send a s=
egmentation fault message and leading to program termination.Smart pointers=
 has this problem too because even when you dereference a smart pointer thi=
s can still happen. (I guess that is why even garbage collecting languages =
such as c# or java has their invalid pointer exceptions).&nbsp;</div><div><=
br></div><div>I could have found&nbsp;only&nbsp;one item about this in c++ =
standard document and it is like this: "The effect of using an invalid poin=
ter value&nbsp;(including passing it to a deallocation function) is undefin=
ed." this was under "basic.stc.dynamic.deallocation". As a result such a ca=
tastrophic event is handled differently by different compilers and platform=
s. It is not even calling terminate on my VS2012. I see my stack unwinding =
being done properly only if I use /EHa switch which<a href=3D"http://stacko=
verflow.com/questions/4573536/ehsc-vc-eha-synchronous-vs-asynchronous-excep=
tion-handling"> is said to end in slower and bigger code in x86 and bigger =
code in x64</a>.</div><div><br></div><div>What I am trying to say is C had =
its way of handling such events via signals. Why doesn't C++ has its way of=
 defining those things as exceptions or with something like terminate? If n=
ot please define something more appropriate than RAII for resource handling=
, because stack unwinding calling destructors looks like a lie this way.</d=
iv>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_345_16143555.1354444175001--

.

On 12/02/2012 11:29 AM, zahir.tezcan@gmail.com wrote:
> Since c++ has exception handling mechanism and the inventor of c++ is
> also inventor of some programming paradigms (i.e. RAII) relying on
> exceptions and stack unwinding, why doesn't c++ has standard way of
> handling such events as exceptions but as abnormal program
> termination instead? For example, if I try to dereference an invalid
> pointer system is supposed to send a segmentation fault message and
> leading to program termination.

In general, not every platform / environment may be able to detect
a null pointer value being dereferenced, unless each pointer indirection
is surrounded by appropriate conditions in the generated machine code.
(Systems without MMU are often in that category.)

C does not guarantee (or specify) that you'll get a signal in that
case; it's just "undefined behavior".  Same in C++.  "Undefined
behavior" is intended for cases where prescribing a specific behavior
would be costly (or impossible) to achieve in terms of runtime
overhead on some platforms.

It's certainly allowed for an implementation to throw an exception
in case a null pointer dereference happens, but that might be
rather costly to achieve on some platforms, so the C++ standard
doesn't prescribe it.  (Throwing an exception instead of terminating
the program also might be a surprise to those expecting the
termination on existing systems, because exceptions would be thrown
from places in your code where you weren't expecting any.)

Bottom line: Turning null pointer dereference from undefined
behavior into throwing exceptions turns a bug in your code into
something well-defined.  I think I'd rather have the bug fixed.

Jens

--




.