"Scott Robert Ladd" <scott@coyotegulch.com> writes:

>> Since signals are part of the standard, and your suggested
>> change would severly affect the current use of this standard
>> feature on Unix platforms, the posting was on-topic as
>> illustrating exactly that fact.

>But should the standard be limited because it might upset a specific system?
>MS is roundly (and in most cases, correctly) criticized for its refusal to
>implement Standard features that invalidate existing code; shouldn't UNIX
>users also be criticized for rejecting a suggested change in the standard
>because it doesn't work with UNIX?

The important point is not that the OS category is Unix, but
that you propose a CHANGE in language definition. The change
would break significant numbers of standard-conforming programs
on popular operating systems, as well as breaking C compatibility.

That is, code that expects to deal with signals according to the C
(and current C++) language definition would stop working.

Unix is merely a convenient and somewhat compelling example.

More generally, whatever goes into the standard is binding on
ALL implementations that wish to claim conformance. The more
systems you exclude by adding requirements that are too expensive
to implement, the less useful the standard becomes.

A standard that no one follows is pointless. To gain acceptance,
a standard must satisfy a wide range of users and implementors.
Nobody gets everything they want; everybody gets a useful subset
of what they would like.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka wrote:
>
>
> Since signals are part of the standard, and your suggested
> change would severly affect the current use of this standard
> feature on Unix platforms, the posting was on-topic as
> illustrating exactly that fact.

Excuse me?  Where does the C++ standard say anything about
UNIX SIGNALS or hardware exceptions (which is what they
embody).  The only passing reference is to the mention
of signals in the C library spec.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie wrote:
>
> Christopher Eltschka wrote:
> >
> >
> > Since signals are part of the standard, and your suggested
> > change would severly affect the current use of this standard
> > feature on Unix platforms, the posting was on-topic as
> > illustrating exactly that fact.
>
> Excuse me?  Where does the C++ standard say anything about
> UNIX SIGNALS or hardware exceptions (which is what they
> embody).  The only passing reference is to the mention
> of signals in the C library spec.

The C++ standard includes the C standard by reference.
And the C standard defines signals (not specifically
UNIX signals, of course).
Also note that while many signals come from hardware exceptions,
not all do. You can raise a signal per software, and some
signals are only raised that way.

Since under Win32, hardware exceptions are translated into
structured exceptions, but conforming compilers must provide
signals as well, I guess on those implementations the
_only_ way to raise a signal is by software (unless the
implementation decides to translate structured exceptions
into signals).


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Robert Ladd wrote:
>
> Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote...
> > In the posting I replied to you suggested that signals should
> > be replaced by exceptions in C++.
>
> I probably wasn't clear.
>
> What I'm looking for is a *portable* solution to the problem of handling
> non-exception events under Standard C++. I realize that every operating
> system is going to have extensions; I was just hoping that there'd be a way
> of handling the "Standard" signals via exceptions.
>
> My current analysis: Certain kinds of exceptions *can't* be handled in a
> portable way. I hate it when reality intrudes on my intended fantasies...

Only synchronous events can be turned into exceptions anyway
without making exception safe programming nearly impossible.
Except if there's a strategy that asynchronous exceptions
can be thrown only at certain points. Now I don't see how this
could be implemnented without great overhead in the normal
execution path (except by giving the implementation debugger
capabilities and setting a breakpoint at the next "exception
checkpoint").
Also, with asynchronous exceptions, we'd face the problem of
double exceptions:

#include <climits>

void delay(int n)
{
  for(volatile int i=0; i<n; ++i);
}

struct A
{
  ~A() { try { delay(INT_MAX); } catch(...) {} }
};

int main()
{
  try
  {
    throw 0;
  }
  catch(...)
  {
  }
}

What should happen if an asynchronous exception happens after
the throw 0, but before the corresponding catch?
And should the behaviour depend on if the exception happens
prior, during or after the try block inside A::~A()?

So your suggestion of turning all signals into exceptions
has language-internal problems as well.

[...]

> > Since signals are part of the standard, and your suggested
> > change would severly affect the current use of this standard
> > feature on Unix platforms, the posting was on-topic as
> > illustrating exactly that fact.
>
> But should the standard be limited because it might upset a specific system?

Unix is not a specific system, it's a whole class of operating
systems (like Linux, HP-UX, Solaris, AIX, Sinix, Irix, BSD...).
Moreover, it's that class where the C language originally
comes from. And finally, there's a standard (POSIX) which is
built from Unix (and doesn't WinNT have a POSIX subsystem
as well?). This standard also relies on signal semantics, and
therefore it would be hard to fit it on C++.

> MS is roundly (and in most cases, correctly) criticized for its refusal to
> implement Standard features that invalidate existing code; shouldn't UNIX
> users also be criticized for rejecting a suggested change in the standard
> because it doesn't work with UNIX?

It is a great difference if a single compiler doesn't
conform, or if some proposed feature doesn't work well
with a given operating system (that is, every conforming
implementation on that OS would be useless), let alone
a whole class of operating systems.
I would strongly suspect that anything that would
not work well with Win32 would have little chance to get
in the standard as well.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote...
> In the posting I replied to you suggested that signals should
> be replaced by exceptions in C++.

I probably wasn't clear.

What I'm looking for is a *portable* solution to the problem of handling
non-exception events under Standard C++. I realize that every operating
system is going to have extensions; I was just hoping that there'd be a way
of handling the "Standard" signals via exceptions.

My current analysis: Certain kinds of exceptions *can't* be handled in a
portable way. I hate it when reality intrudes on my intended fantasies...

> It isn't. If there had been the suggestion that catching
> division by zero with catch(...) should be disallowed,
> and you had answered that this probably would be disliked
> by most Win32 users, since this is how it currently works
> on Win32, it would have been on-topic as well.
> Indeed, if you look at the originating thread, you'll find
> more Win32 details than Unix details. So by simple counting,
> I'd have to conclude that this is Win32-biased...

Hmmmm... your last sentence above might be correct. For my purposes, I'm not
interested in anything Microsoft-specific, because it would be no more
useful to me than something UNIX-specific.

As for implementation specifics: I have no problem with them in the
newsgroup if they're related to the Standard somehow. I just think some
people have an irrational bias against MS...

> Since signals are part of the standard, and your suggested
> change would severly affect the current use of this standard
> feature on Unix platforms, the posting was on-topic as
> illustrating exactly that fact.

But should the standard be limited because it might upset a specific system?
MS is roundly (and in most cases, correctly) criticized for its refusal to
implement Standard features that invalidate existing code; shouldn't UNIX
users also be criticized for rejecting a suggested change in the standard
because it doesn't work with UNIX?

--
  *     Scott Robert Ladd
  *     Coyote Gulch Productions - http://www.coyotegulch.com




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Robert Ladd wrote:

> It's not that I'm against discussing implementation-specifics, since it is
> clear that the Standard is more of an ideal than a reality. But: When
> someone brings up a Microsoft-specific issue or solution, it tends to get
> swatted down as off-topic. Why is UNIX more on-topic than MS?

I see lots of posts the gist of which is: VC++ works in this way, is this
standard C++. Personally I am tired of seeing C++ treated as VC++, since for
Windows I use C++ Builder ( yes, there are other C++ compilers ). It hardly
seems to me that MS is swatted down. Au contraire, I believe this forum
tolerates a huge number of questions about how VC++ works as opposed to how C++
is defined. Maybe this should be called MS being unnecessarily propped up rather
than swatted down <g>.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Scott Robert Ladd" <scott@coyotegulch.com> writes:

>Just an observation...

>In the discussion of numerics and exceptions, several people have brought up
>"this is how this works on UNIX". All fine and dandy, if this weren't a
>group devoted to discussing the STANDARD. The Standard does not define
>SIGPIPE or sigalert, but these were presented as arguments in regard to
>issues I raised about Standard C++.

>It's not that I'm against discussing implementation-specifics, since it is
>clear that the Standard is more of an ideal than a reality. But: When
>someone brings up a Microsoft-specific issue or solution, it tends to get
>swatted down as off-topic. Why is UNIX more on-topic than MS?

Speaking as one of the moderators, I don't believe that is the case.

We have many examples in several current threads of MS used for
examples without rejection by the moderators or complaints from
other readers.

If someone posts an MS-specific (or Apple-specific, or Unix-specific)
question, it will ordinarily be rejected by the moderators. The
FAQ has considerable discussion on this point.

But often in discussion of language features and rules it is
helpful to provide examples from one or more specific systems.
That is acceptable, and common.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Just an observation...

In the discussion of numerics and exceptions, several people have brought up
"this is how this works on UNIX". All fine and dandy, if this weren't a
group devoted to discussing the STANDARD. The Standard does not define
SIGPIPE or sigalert, but these were presented as arguments in regard to
issues I raised about Standard C++.

It's not that I'm against discussing implementation-specifics, since it is
clear that the Standard is more of an ideal than a reality. But: When
someone brings up a Microsoft-specific issue or solution, it tends to get
swatted down as off-topic. Why is UNIX more on-topic than MS?

Note: I program in both UNIX and Windows, trying to write truly portable
code that matches the Standard. Yes, I'm also a technological masochist...
;}

--
  *     Scott Robert Ladd
  *     Coyote Gulch Productions - http://www.coyotegulch.com





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Robert Ladd wrote:
>
> Just an observation...
>
> In the discussion of numerics and exceptions, several people have brought up
> "this is how this works on UNIX". All fine and dandy, if this weren't a
> group devoted to discussing the STANDARD. The Standard does not define
> SIGPIPE or sigalert, but these were presented as arguments in regard to
> issues I raised about Standard C++.

In case you are referring to my posting in the thread "signals
and exceptions" (I think so, since you mention SIGPIPE & co.):

In the posting I replied to you suggested that signals should
be replaced by exceptions in C++.
Now I gave a lot of examples of signals in Unix, which should
not be converted to Exceptions. This is relevant to
standardisation, because your suggestion would cause major
griefs to every single C++ implementation on Unix.

Since signals are part of the standard, and your suggested
change would severly affect the current use of this standard
feature on Unix platforms, the posting was on-topic as
illustrating exactly that fact.

If I had discussed when a SIGPIPE should be raised under Unix,
or how to use SIGUSR1 correctly, or about Unix-specific
functions about signal handling, and if the SysV way is better
or worse than the BSD way, it would have been off-topic.

>
> It's not that I'm against discussing implementation-specifics, since it is
> clear that the Standard is more of an ideal than a reality. But: When
> someone brings up a Microsoft-specific issue or solution, it tends to get
> swatted down as off-topic. Why is UNIX more on-topic than MS?

It isn't. If there had been the suggestion that catching
division by zero with catch(...) should be disallowed,
and you had answered that this probably would be disliked
by most Win32 users, since this is how it currently works
on Win32, it would have been on-topic as well.
Indeed, if you look at the originating thread, you'll find
more Win32 details than Unix details. So by simple counting,
I'd have to conclude that this is Win32-biased...

As far as I understand it, implementation specifics are
on-topic if they are related either to the question if that
behaviour is conforming, or with the question, if a certain
behaviour should be mandated or disallowed by the standard.

A system specific _solution_ doesn't fit in either categry,
of course.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Robert Ladd wrote:
...
> It's not that I'm against discussing implementation-specifics, since it is
> clear that the Standard is more of an ideal than a reality. But: When
> someone brings up a Microsoft-specific issue or solution, it tends to get
> swatted down as off-topic. Why is UNIX more on-topic than MS?

It isn't. You should do some reverse swatting whenever you see such
comments. However, examples from both MS and UNIX are on-topic, when
claiming that "that isn't portable - for example, it won't work on this
conforming implementation for this reason".
The problem, of course, is coming up with an implementation that even
comes close to being conforming on MS.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Scott Robert Ladd" <scott@coyotegulch.com> wrote:
> Why is UNIX more on-topic than MS?

Remember the place of your birth .... :-)

Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]