Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-09-28 11:59:50

David Abrahams wrote:
> From: "Alexander Terekhov" <terekhov_at_[hidden]>
> > David Abrahams also wrote: <another article>
> > [...]
> > > > especially if you are trying to
> > > > write safe portable code (besides, they could be implemented as
> > > "really-C++"
> > > > exceptions on a given platform too).
> > >
> > > In that case, try/catch would be fine.
> >
> > Nope. You wouldn't really want to ALWAYS have {partial} unwinding on
> > std::logic_error
> I don't really have a choice.
> > (unless you *really really* want it for some reason
> > that is beyond my understanding and/or imagination), would you? ;-)
> I really wouldn't want std::logic_error in the first place, but if someone
> is so foolish as to throw one, there *will* be stack unwinding. That's how
> exceptions work (yeah, I know there are conditions under which you can
> terminate without unwinding, but that's what assert/abort() is for).

But there are really quite a few "corner cases" when the caller/user
should have a right to decide whether this or that exception is meant
for local recovery (will be caught) or should rather result in a nice
core dump (at throw point) with recovery actions being done on some
higher level. I'll try to give an example: on mainframes programmers
are supposed to document address space size requirements (depending on
the config/input/workload) for their programs. System programmers and
operators use this information for capacity planning, etc. in order to
achieve "reasonable" performance/throughput on their systems (or just
buy "more hardware" ;-) ). They really don't want to see those dumb
"out-of-memory" errors. Quite often, running out of memory just means
that something was leaking/looping and/or the calculations were just
wrong. In any event, our service folks really want to see a full dump,
instead of kinda silly: "catch(const std::exception& e) { cerr <<
e->what(); exit( EXIT_FAILURE ); }"-like stuff.

> > Frankly, do YOU *also* kinda "doesn't seem to care"(*) with respect
> > to thread cancel/exit safety of your code (given that sort of "brain-
> > dead" *forced unwinding* IS adopted by many many C++ vendors/platforms
> > presently)? What am I missing, Mr. Abrahams?
> I don't seem to care so much because most of my code isn't written with
> thread safety in mind and doesn't have to run in multithreaded contexts.
> I'll worry about that when I have users who need it, knowledge of the
> platforms I'm targeting, and an environment in which to test what I've
> done.

Fair enough. If/when you'll see PJP, please drop these links "on him":
("Standard C++ Library Reference,...The documentation, which is available at")
("1.2.3 Class libraries")

 z/OS V1R2 C/C++ provides the following class libraries,
 which are all thread-safe:

 Standard C++ Library, including the Standard Template Library (STL),
 and other library features of ISO C++ 1998

<pretty much the same goes for AIX/IBM Visual Age C++ as well>


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