Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-10-13 15:26:41

< Forward Inline, FYI >

-------- Original Message --------
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: why still use C?
References: ... <clcm-20031008-0017_at_[hidden]>

thp_at_[hidden] wrote:
> C is pretty much, but not quite, a sublanguage of C++. C programmers
> who don't use the non-C++ features of C are programming in C++ whether
> they claim to or not. They are restricting themselves to an older,
> more established, more easily learned, and more easily implemented
> subset of C++. But they are writing in C++ --- non-idiomatic C++, but
> C++ nevertheless. AFAIK, a C++ compile is free to generate the same
> code for those programs as would a C compiler, so there is no
> intrinsic difference in performance.

In C without exceptions (stuff like MS or DEC/HP SEH extensions), all
functions are kinda "throw()". In the current C++ (without mandatory
2-phase EH and with brain-damaged exception specifications instead),
throw() is kinda expensive. So, there is some "intrinsic difference
in performance", I'm afraid.


P.S. WRT to the last link: "Stack overflow is no problem on *entry*
to a throw() region..." is about explicit throw()-regions apart from
scope cleanup -- I mean {throw()-nothing} dtors... they shall have
implicit throw() ES by default, of course. We just can't retry thier
destruction because objects are gone. Optional stack checking (for
objects that live in throw-something routines) can be done prior to
construction (and, of course, the entire "landing pad" shall to be
protected by MS SEH like "__try/__except(goto_unexpected()) {}" or
"something like that").



The runtime transfers control to a landing pad whenever an exception
is thrown from a given call site. The landing pad contains code in
the following order:

- compensation code, restoring program state to what it would be if
  optimizations had not been done in the main control flow;

- destructor invocation to destroy any local object that needs to be

- exception switches to select which catch handler, if any, to jump
  to (an appropriate switch value is computed by the runtime from
  the C++ exceptions table and placed in a temporary register); and

- a landing pad exit, which either returns to a catch block and
  moves from there to the main control flow or resumes unwinding if
  no appropriate exception handler is found in this subroutine.


- If the variable is allocated to a different register in different
  sections of code, the landing pad can simply copy that register to
  the target register that represents the variable in the exception

- A value known to be constant that is replaced with the constant
  value can be loaded into the appropriate register by the landing
  pad, for use by the user code in the exception handler.

- Pending memory operations that have been delayed in the main
  control flow can simply be executed in the landing pad should an
  exception be thrown. Compensation code therefore lets the compiler
  use any of the optimizations that were prevented by simpler table-
  driven techniques.



Boost list run by bdawes at, gregod at, cpdaniel at, john at