James Kanze wrote:
> The only cost is thus a bit more disk space for the executable.  On
> embedded systems where the entire code must be PROMable, this might
> make a difference.  Elsewhere, I can hardly imagine it.
 BTW, did anybody try to implement an exception handling via old good return
statements? I.e.

 void g1(), g2();

 void f()
 {
  g1();
  g2();
 }

 void g1()
 {
  // 1
  throw E();
  // 2
 }

turns into the something like this:

 extern bool InException;  // something thread safe

 void f()
 {
  g1();
  if (InException) return;

  g2();
 }

 void g1()
 {
  // 1
  CopyAndSave(E());
  InException=true;
  return;
  // 2
 }

IMHO this schema doesn't involve a significant overhead and can compete (even
:) with a plain C.
--
         With all respect, Sergey.          http://cpp3.virtualave.net/
         mailto : ders at skeptik.net

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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 <3A2FAA06.34B4043D@iobox.com>, Sergey P. Derevyago wrote:

>  BTW, did anybody try to implement an exception handling via old
> good return statements?

According to Lippman's "The C++ Object Model", further development of
AT&T's original C++-to-C compiler (cfront) was stopped because of EH
implementation difficulties.  I bet they tried good old return statements
before giving up.

- Wil

--
Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
[Wil underscore Evers at doosys dot 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.research.att.com/~austern/csc/faq.html                ]

"Sergey P. Derevyago" wrote:
>
> James Kanze wrote:
> > The only cost is thus a bit more disk space for the executable.  On
> > embedded systems where the entire code must be PROMable, this might
> > make a difference.  Elsewhere, I can hardly imagine it.
>         BTW, did anybody try to implement an exception handling via old good return
> statements? I.e.

[...]

> IMHO this schema doesn't involve a significant overhead and can compete (even
> :) with a plain C.

What is "significant overhead" probably depends on your view.
If throwing exceptions is really the exception, and run time
is more important than space, your suggestion obviously has
_more_ overhead than the table driven method, which costs
_zero_ execution time (except for missed optimisations) as
long as no exception is thrown.

BTW, I also have a (possibly silly) idea about exception
handling (which possibly only works on x86 CPUs - I don't
know if others would have support for this, but I expect not):

The x86 uses a "segment:offset" addressing. Now for 32 bit
programs usually the whole program is in just one
segment, and therefore uses "near" calls/returns, that is,
only the offset part is changed, the segment part is not.
Now my idea is the following: What if the program actually
used _two_ segments, where the "normal" code is in one, and
special EH "unwinding" code is in the other, where the
special trick is that the EH code begins _at the same offset_
as the corresponding normal return address (the very first
EH statement can be a jump if there's not enough space at
that address for EH code). Now throw (after constructing
the EH object) calls a function which just exchanges the
code segment from "normal" to "eh", and returns. Now due to
the special code alignment, the normal "near returns" does
the correct stack unwinding (replacing the expensive table
lookups). Destructor calls would go through a special
function in the "normal" code segment, which - unlike the
other functions - is called with a far call (so the code
segment is automatically corrected). As a bonus, the return
address of the destructor called by stack unwinding is
always at a fixed address (offset), therefore the double
exception handling code could just be put at that offset
in the "eh" segment.

This would IMHO speed up throwing exceptions quite a bit,
because the normal processor handling of returns does
almost all of the stack unwinding logic (and the actual
cleanup work is done with function specific code generated
by the compiler during compilation). The only extra
cost would be the segment switching on throw, one extra
far call/return per destructor call, the RTTI work to
determine the catch handler to be used (this cannot be
avoided), and the final CS switch to get to the catch
(probably a simple far jump).
The "normal" code page would contain nothing at all from
EH, except the construction of the exception object, the
catch handler code, and two small support functions. If
a program wants to get rid of EH support for space reasons,
the "eh" segment is just removed - trying to throw will
simply cause a segmentation fault and therefore terminate
the program.

It would, of course, complicate the compiler (which has
to make sure that everywhere an exception may occur there
exists an appropriate entry point in the "eh" segment).
---
[ 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.research.att.com/~austern/csc/faq.html                ]