Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #30093

Re: The (anti) C++ FQA Lite -- worth a look

Show all headers | View raw

On Thu, 24 Jul 2014 12:28:08 -0500
"Osmium" <r124c4u102@comcast.net> wrote:
> "Chris Vine" wrote:
[snip]
> > 
> > I have never seen anyone equate asynchronous signals with exceptions
> > (using the word "exceptions" in its normal programmatic sense).
> > They
> > are completely different things.  I believe microsoft may have
> > implemented some hardware faults as programmatic exceptions outside
> > the C++ standard, which would instead trigger an asynchronous signal
> > in unix-like environments, but that is as close as it gets.
> > 
> > Perhaps you meant to refer to escape continuations as implemented by
> > setjmp() and longjmp(), which are in setjmp.h rather than signal.h,
> > and which can be used as a poor-man's exception mechanism in C?
> > They
> > are valid in C++ subject to §18.10/4 of the C++11 standard - in
> > particular you cannot jump up the call stack out of a scope in which
> > there are objects with non-trivial destructors.  Presumably the
> > decision was taken by the standards committee to retain the C
> > behaviour of longjmp() in simply wiping out any stack objects jumped
> > over, rather than to unwind the stack as in the case of exceptions.
> > It could have gone either way.  However C-style escape continuations
> > are much more limited in use than C++ exceptions.  Their behaviour
> > in
> > C++ could have more closely followed the behaviour of C++
> > exceptions,
> > but they could not have replaced C++ exceptions.
> 
> I prefer to think of _anomalies_, rather than errors or exceptions, 
> something out of the ordinary happened.  I also had in mind the error 
> functions in <stdio.h> as well, but nothing was further from my mind
> than setjmp and longjmp.  ISTM that if one knew at the outset of the
> design of a computer language that anomalies would have to somehow be
> taken care of, a sufficiently clever person could integrate these
> things together.  Gather your thoughts, focus on design, defer the
> naming of this thing till towards the end.

Your news reader has mangled the attribution.  I have corrected it
above to distinguish between my text and your text.

It is worth remembering the origin of signals, which was to enable
the operating system to report system events outside the programmatic
flow of control of the program to a single threaded program.  In a
single threaded program the easiest thing is for the system to
interrupt the single thread of execution of the program asynchronously,
which is what it does.  (The requirement only to call async-signal-safe
functions in a signal handler makes them barely usable today.  In most
cases these days the best way to deal with signals is to handle them in
a dedicated thread using sigwait() as an asynchronous-to-synchronous
converter.)

You seem to want something different.  You seem to want an operating
system which uses C++ exceptions (or something similar) to report events
occurring outside the flow of control of the program for which
unix-like systems currently use signals.  Maybe, but the C++ language
cannot mandate that, because that is not something unix-like systems
will ever do, because C does not support exceptions.  And the
C++ standard committee wants C++ to run on operating systems
implemented with and runnable by C.  (A wise choice by the way.)

This is a matter for the operating system.  Some of the IBM
operating systems do something similar to what you want.  I think
windows provides limited support for it as an extension, for such
things as null pointer dereferencing and out-of-range integers and
floating points (but I don't program for windows).  I think
cocoa also has some support for it.  However, this approach is not free
of all problems.  In particular, if you cannot have some of your
functions guaranteed not to throw exceptions, you cannot write
exception-safe code.  How then would you deal with unmaskable hardware
events?  And what do you do where the fault means that the stack
cannot be safely unwound?  Most operating systems end up using something
similar to signals for at least some events.

In any event, your original point was that you thought C++ should have
implemented its programmatic exceptions using C signals.  That is
impossible.  As I said, they are fundamentally different.

> I was trying to focus on one thing.  But since you brought it up, why
> did the C++ language need setjmp and longjmp?  As a matter of fact
> why did they need printf? Was the thought that <stdio.h> can be
> taught a minute ot so? C++ is a *language*, right?  Not some dialect
> of some other language. You can learn English without knowing Latin
> or anything else.

You have lost me, but on why setjmp() and longjmp() are in C,
presumably because simple escape continuations were thought to be
useful for implementing error handling in some programs.  Maybe the
authors of C were influenced by lisp dialects such as scheme.  Scheme
was somewhat popular at the time (at least amongst the academic
community) and supports callable continuations, which can be used to
implement exceptions and coroutines.  As it happens, I have used C
libraries which have employed setjmp/longjmp for handling particular
error conditions.

> BTW, K&R use the word "exceptions" WRT <signal.h>in their obscure
> little book.

They meant interrupts or "CPU exceptions".  Same word, different
meaning.

Chris

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

The (anti) C++ FQA Lite -- worth a look "K. Frank" <kfrank29.c@gmail.com> - 2014-07-16 08:06 -0700
  Re: The (anti) C++ FQA Lite -- worth a look Öö Tiib <ootiib@hot.ee> - 2014-07-16 16:12 -0700
    Re: The (anti) C++ FQA Lite -- worth a look "K. Frank" <kfrank29.c@gmail.com> - 2014-07-18 09:39 -0700
      Re: The (anti) C++ FQA Lite -- worth a look Öö Tiib <ootiib@hot.ee> - 2014-07-19 03:48 -0700
    Re: The (anti) C++ FQA Lite -- worth a look Juha Nieminen <nospam@thanks.invalid> - 2014-07-24 05:36 +0000
      Re: The (anti) C++ FQA Lite -- worth a look "Osmium" <r124c4u102@comcast.net> - 2014-07-24 10:08 -0500
        Re: The (anti) C++ FQA Lite -- worth a look Bo Persson <bop@gmb.dk> - 2014-07-24 18:00 +0200
        Re: The (anti) C++ FQA Lite -- worth a look Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2014-07-24 17:36 +0100
          Re: The (anti) C++ FQA Lite -- worth a look "Osmium" <r124c4u102@comcast.net> - 2014-07-24 12:28 -0500
            Re: The (anti) C++ FQA Lite -- worth a look Dombo <dombo@disposable.invalid> - 2014-07-24 23:50 +0200
              Re: The (anti) C++ FQA Lite -- worth a look Juha Nieminen <nospam@thanks.invalid> - 2014-07-25 05:36 +0000
                Re: The (anti) C++ FQA Lite -- worth a look Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-07-25 18:18 +0000
            Re: The (anti) C++ FQA Lite -- worth a look Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2014-07-24 23:29 +0100
              Re: The (anti) C++ FQA Lite -- worth a look Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2014-07-24 23:45 +0100
                Re: The (anti) C++ FQA Lite -- worth a look scott@slp53.sl.home (Scott Lurndal) - 2014-07-25 14:05 +0000
                Re: The (anti) C++ FQA Lite -- worth a look Juha Nieminen <nospam@thanks.invalid> - 2014-08-04 05:59 +0000
                Re: The (anti) C++ FQA Lite -- worth a look scott@slp53.sl.home (Scott Lurndal) - 2014-08-04 14:52 +0000
                Re: The (anti) C++ FQA Lite -- worth a look Juha Nieminen <nospam@thanks.invalid> - 2014-08-05 06:57 +0000
                Re: The (anti) C++ FQA Lite -- worth a look Öö Tiib <ootiib@hot.ee> - 2014-08-05 05:53 -0700
                Re: The (anti) C++ FQA Lite -- worth a look Martijn Lievaart <m@rtij.nl.invlalid> - 2014-08-05 16:20 +0200
                Re: The (anti) C++ FQA Lite -- worth a look Öö Tiib <ootiib@hot.ee> - 2014-08-05 16:58 -0700
                Re: The (anti) C++ FQA Lite -- worth a look Juha Nieminen <nospam@thanks.invalid> - 2014-08-07 11:04 +0000
                Re: The (anti) C++ FQA Lite -- worth a look scott@slp53.sl.home (Scott Lurndal) - 2014-08-05 14:27 +0000
                Re: The (anti) C++ FQA Lite -- worth a look Juha Nieminen <nospam@thanks.invalid> - 2014-08-07 11:06 +0000
    Re: The (anti) C++ FQA Lite -- worth a look Thomas Richter <thor@math.tu-berlin.de> - 2014-07-28 21:01 +0200
      Re: The (anti) C++ FQA Lite -- worth a look Öö Tiib <ootiib@hot.ee> - 2014-08-03 16:22 -0700

csiph-web