🚀 go-pugleaf

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.

---
Steve Clamage, stephen.clamage@eng.sun.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. ]