🚀 go-pugleaf

In article <4dos4l$ra9@engnews1.Eng.Sun.COM>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>In article k04@wcap.centerline.com, chase@centerline.com (David Chase) writes:

>I'm more than willing to assume your implementation technique has merit.
>Yet didn't you say you were not able to get it approved? So what
>is a C++ implementor to do if the only reasonable implementation
>technique violates the platform ABI?

Use of techniques not mandated by the ABI does not necessarily
"violate" the ABI.  For instance, Sun's current C++ product uses
PC-ranges, yet these are not discussed in the ABI.  Note that the C++
subroutines interoperate with ABI-conforming subroutines.  Placing
something like that in the ABI merely helps reduce the chance that
each and every language and vendor will do something different and
non-interoperable.  The actual reasons why it didn't make it in had a
lot less to do with technology, and more to do with intercompany
politics (and I must admit that I did not explain myself well at the
time).

>I want to say again that a criterion for a feature in the standard is not
>whether you can somehow implement it on some systems. The criterion is more
>like whether you can implement it with appropriate efficiency on all
>systems and not adversely affect programs that don't use the feature.
>If a feature does not meet this criterion, it has to be widely beneficial
>to justify its inclusion.

Well, most programs I've seen (Sparc, 386, 68K, VAX) used pretty
simple calling sequences, even in the presence of some scheduling, and
those programs aren't adversely affected by this.  It's efficient on
all reasonable systems (I haven't figured out how it would work on a
B1700, for example), and I've had my ear bent talking to people (at
Sun) doing video about how brain-dead they think it is to not have
asynchronous exceptions.  Furthermore, I fully expect that people will
do stupid stuff in signal handlers, no matter what the standard says.
I realize that there are difficulties (how much of the constructor has
completed?) but they aren't related to maintaining consistent
activation records.

Really, this is slightly pointless -- I had this argument with other
people years ago, and I know that it will have no effect on the
language.  However, it is simply not the case that it is difficult to
maintain consistent activation records in the presence of asynchronous
exceptions.

speaking for myself,

David Chase
---
[ 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. ]