[boost] Re: std::expected_exception

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.

http://lists.boost.org/MailArchives/boost/msg53807.php
http://lists.boost.org/MailArchives/boost/msg53808.php
http://lists.boost.org/MailArchives/boost/msg53826.php

regards,
alexander.

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").

<quote>

LANDING PADS

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 
  destroyed;

- 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.

 <snip>

- 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 
  handler.

- 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. 

</quote>

regards,
alexander.