🚀 go-pugleaf

> ==========Steve Clamage, 1/22/96==========
 
> In article 8k8@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
> >Steve Clamage (clamage@Eng.Sun.COM) wrote:
 
> >: What we put in the language standard is binding on all
> implementations. We
> >: try to specify things that can be implemented efficiently on
> any likely
> >: system. In addition, we try to specify features so that they
> have no cost
> >: (or nearly no cost) if you don't use them. IMHO, guarantees
> about what you

> >Agreed!!

> >: can do in an asynchronous signal handler don't meet those
criteria for
> >: inclusion in the C++ standard.

> >That's a rather broad conclusion, given the discussion so far.

> I don't agree. If you have control over the entire environment, you can
> make more guarantees about behavior. For example, Ada implementations
> have extensive requirements on what they must support. If a platform
> cannot reasonably meet those requirements, you aren't going to find an
> Ada implementation which is both conforming and useful.
 
> C++, on the other hand, is intended to be dropped into (nearly)
> any existing
> platform and coexist with other languages on that platform.
The language
> definition attempts to stay away from areas where common platforms have
> widely differing behavior for that reason. Asynchronous signal handling
> certainly varies widely among platforms.
> 
> It's easy to wave your hands and say that the implementation ought to
> be relatively easy to do and not overly expensive. But what if the ABI
> on a common platform makes that infeasible? If a language feature
> limits the number of platforms which allow implementation, it should be
> important to a wide range of programmers and programs.

It is important for asynchronous threads that may interrupt other
threads (signal handlers, interrupt handlers, ...) to be able to use
the same exception semantics that any thread would use.  Else
you must define two sets of C++ behavior and STL, new, etc., must
all work in both.  You made exceptions part of the language, but
they still seem to be second class citizens.  Until they are made
first class citizens, you will continue to have a lot of arguing about
inherent problems of them being second class.

This is just one case where trying to limit the standard to ALL
potential environments seems to be hurting the thinking and
the language.  I suspect that essentially all environments can
actually do something sensible.  If a few cannot, they should
be exceptional, in that area, to the standard.

Good Day
Dick
Dick.Menninger@DaytonOH.ATTGIS.COM
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]