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

Groups > comp.lang.c++ > #29977 > unrolled thread

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

Back to article view | Back to comp.lang.c++

Contents

  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

Page 1 of 2  [1] 2  Next page →

#29977 — The (anti) C++ FQA Lite -- worth a look

Hello Group!

I just came across Yossi Kreinin's C++ FQA Lite:

   http://yosefk.com/c++fqa/

(dated 2007-2009).

It's modeled on and parodies Marshall Cline's C++
FAQ Lite (http://www.parashift.com/c++-faq-lite/).

It's mostly an anti-C++ polemic, but buried in the
expected snark is some good technical discussion.
Worth a look, if only as refresher on various C++
subtleties and oddities.


Happy Hacking!


K. Frank

[toc] | [next] | [standalone]

#29978

On Wednesday, 16 July 2014 18:06:53 UTC+3, K. Frank  wrote:
> Hello Group!
> 
> I just came across Yossi Kreinin's C++ FQA Lite:
> 
>    http://yosefk.com/c++fqa/
> 
> (dated 2007-2009).

Why he stopped updating that thing so long ago?

> It's modeled on and parodies Marshall Cline's C++
> FAQ Lite (http://www.parashift.com/c++-faq-lite/).
> 
> It's mostly an anti-C++ polemic, but buried in the
> expected snark is some good technical discussion.
> Worth a look, if only as refresher on various C++
> subtleties and oddities.

The oddities and subtleties won't go never anywhere because of need
for backwards compatibility of code with C and with earlier versions
of C++ to cheapen transition of blackbillions of lines of C++ code
to newer compilers. However most of the things he does not need to 
use or are not issues.

Lets take a look at "Defective C++" list of his:

"No compile time encapsulation": Private member functions can be 
hidden with by using opaque inner or opaque friend class idiom.
Private data can be hidden by using pimpl pattern. Work has been
done for introducing modules, but not yet there.

"Outstandingly complicated grammar": C++11 added enough grammar
so each thing is possible to write in a way that it can mean only
one thing regardless of context. No need to use ambiguous or
context-specific grammar. Write a plugin for code editor that 
underlines such red.

"No way to locate definitions": No one is requiring developers to
misuse unmaintainable forest of #include files. Work has been
done for introducing modules, but not yet there. So far use 
a code editor that helps with it.

"No run time encapsulation": Don't use C arrays if you can't handle
the code you get. Use 'std::array::at' or 'std::vector::at' to get
exception for accessing array out of bounds. Requiring that others
get run-time bounds check that they do not need/want is silly.

"No binary implementation rules": That is plain idiocy. Programming
language is for describing (compile-time and run-time) behavior of
software and not produced binaries. Assemblers are for achieving
certain binaries.

"No reflection": Latest proposals about it are so good that Qt
team considers their 'moc' utility removable or almost so. He does
not sound like developer who can use reflection for anything 
anyway so why he cares?

"Very complicated type system": How he insists to write complex
programs without complex types? As for tools showing too much 
information in diagnostics ... use better tools.

"Very complicated type-based binding rules": True. 
Argument-dependent lookup, overload resolution and template 
specialization and name hiding goes with rather powerful rules. 
He is even wondering why FAQ did not have any questions. It is 
because no one does ever need to write something that challenges
power of those rules.

"Defective operator overloading": Works brilliantly for me, but
if it is too complex for him then why he overloads these 
operators anyway? Write a plugin to code editor that warns 
against overloading operators.

"Defective exceptions": He was technically telling that he has
never profiled neither exceptions nor RAII. IOW some sort of 
FUD of ignorant that those are expensive.

"Duplicate facilities": That is exactly what one means with
full tool-set. Does it make tool-set of carpenter worse that
there are  more than one device for certain works (like 
for screwing or for nailing)? Is there problem if he never 
uses some of those now? Is there problem that he used some 
of those more excessively before? Write a plugin to your
code editor that warns about usage of facilities you consider
"obsolete".

"No high-level built-in types": That is actually good how C++
has managed to keep core language and its library almost separate.
Few slips away from that, especially 'std::initializer_list' 
I hate the most.

"Manual memory management": Again just demonstration of complete
lack of understanding of RAII. My recent code contains zero 
instances of keywords 'new' and 'delete' used and last memory
leak I had over 10 years ago. Write a plugin to your
code editor that underlines 'new' and 'delete' fat red.

"Defective metaprogramming facilities": He does not indicate much
familiarity with Lisp (that has indeed better meta-programming
facilities than C++2003). So why he needs those?

"Unhelpful standard library": There are so numerous problem 
domains where C++ is used that having library support for all
in single standard library would make one's head explode.
More generally useful things are in Boost libraries. Few would
want to have all Boost (and more) in standard library. More 
problem-specific things are in thousands of problem-specific
libraries all over the world. One should not whine about 
"Duplicate facilities" and "Unhelpful standard library" in
same list.

"Defective inlining": Standard C++ does not contain support
for programmer-induced inlining. I know no programming languages
that have programmer-induced inlining. The keyword "inline" 
in C++ just does allow one to define function in header file 
without violating ODR. Compiler and linker are inlining like 
these see fit.

"Implicitly called & generated functions": Complaining that 
some code is made automatically? Make a plugin for code 
editor that requires you to declare each of such explicitly
either '= default' or '= delete' and marking all (but copy
or move) constructors and conversion operators with 
'explicit'.

[toc] | [prev] | [next] | [standalone]

#30003

Hi Öö!

Thanks for your comments.  I basically agree with
everything you say.

On Wednesday, July 16, 2014 7:12:25 PM UTC-4, Öö Tiib wrote:
> On Wednesday, 16 July 2014 18:06:53 UTC+3, K. Frank  wrote:
> > Hello Group!
> > 
> > I just came across Yossi Kreinin's C++ FQA Lite:
> > ...
> > (dated 2007-2009).
> 
> Why he stopped updating that thing so long ago?

I don't know.  I guess he had his fun with his rant, and
moved on to other things.  (Maybe he could contribute to
this thread.)

> ...
> Lets take a look at "Defective C++" list of his:
> 
> "No compile time encapsulation": Private member functions can be 
> hidden with by using opaque inner or opaque friend class idiom.
> ...

Thanks for your rebuttal.  I found the "Defective C++"
list one of the more annoying parts of the anti-FQA.
It's mostly a rehash of a bunch of the common (and
false and misleading) arguments against C++.

> ...

I should emphasize, in case there was any
misunderstanding, that I disagree with most all of
what Kreinin has to say.

Nonetheless, some of what he says is true, and it
never hurts to remind ourselves that C++ does have
some dark corners, and it's also good to grapple
from time to time with the FUD that gets thrown
at C++, and review the counter-arguments (as you
have done in your post).


Thanks.


K. Frank

[toc] | [prev] | [next] | [standalone]

#30010

On Friday, 18 July 2014 19:39:29 UTC+3, K. Frank  wrote:
> Nonetheless, some of what he says is true, and it
> never hurts to remind ourselves that C++ does have
> some dark corners, and it's also good to grapple
> from time to time with the FUD that gets thrown
> at C++, and review the counter-arguments (as you
> have done in your post).

Indeed. Engineer should consider critically the quality and limits
of tools of his trade (and positive or negative claims about it).

What I may be do not like is his unhelpful attitude that C++ is 
fundamentally broken, so run away from it. It is nonsense since
lot of great software has been written and is written with it. 

However he is correct about no module support, weak meta-programming
facilities, no reflection and weak safety measures in C++. People
who need these things should know that and either use other 
programming languages or tools that aid with that in C++.

[toc] | [prev] | [next] | [standalone]

#30075

Öö Tiib <ootiib@hot.ee> wrote:
> "Outstandingly complicated grammar"
> "No reflection"
> "Very complicated type system"
> "No high-level built-in types"

The guy is just deliberately (and rather desperately) trying to to find
faults. He lists everything he can think of, disregarding any consistency
in his arguments.

The above are a good example of completely inconsistent logic. He both
decries the language being "too complex", and at the same time that it
isn't complex enough, lacking some arbitrary features in some other
languages. The above examples are, basically, "it's too complex",
"it's not complex enough", "it's too complex", "it's not complex enough".

He blows minor things out of proportion, he distorts some features
by deliberately ignoring what they are useful for and only concentrating
on perceived faults, and in some cases he outright fabricates faults
that aren't there at all.

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#30084

"Juha Nieminen" wrote:


> The above are a good example of completely inconsistent logic. He both
> decries the language being "too complex", and at the same time that it
> isn't complex enough, lacking some arbitrary features in some other
> languages. The above examples are, basically, "it's too complex",
> "it's not complex enough", "it's too complex", "it's not complex enough".

I have zero interest in defending the article in question.  But WRT "too 
complex", consider the following.  C++ has an exception mechanism.  C 
provided <signal.h> to handle certain exceptions, which C++ renamed and 
kept. Can't you see how providing two methods to do one thing is more 
complex than providing one method?  This has nothing at all to do with 
whether the approach used to develop C++ was necessary and proper.  It has 
to solely to do with the end result.

[toc] | [prev] | [next] | [standalone]

#30085

Osmium skrev den 2014-07-24 17:08:
> "Juha Nieminen" wrote:
>
>
>> The above are a good example of completely inconsistent logic. He both
>> decries the language being "too complex", and at the same time that it
>> isn't complex enough, lacking some arbitrary features in some other
>> languages. The above examples are, basically, "it's too complex",
>> "it's not complex enough", "it's too complex", "it's not complex enough".
>
> I have zero interest in defending the article in question.  But WRT "too
> complex", consider the following.  C++ has an exception mechanism.  C
> provided <signal.h> to handle certain exceptions, which C++ renamed and
> kept. Can't you see how providing two methods to do one thing is more
> complex than providing one method?  This has nothing at all to do with
> whether the approach used to develop C++ was necessary and proper.  It has
> to solely to do with the end result.
>

Exceptions and signals are two different thing with entirely different 
usages (in C++).

The complexity complaints for the language fall flat when the author lists:

The type system is too complex
Not enough built-in types


Bo Persson

[toc] | [prev] | [next] | [standalone]

#30087

On Thu, 24 Jul 2014 10:08:10 -0500
"Osmium" <r124c4u102@comcast.net> wrote:
> "Juha Nieminen" wrote:
> 
> > The above are a good example of completely inconsistent logic. He
> > both decries the language being "too complex", and at the same time
> > that it isn't complex enough, lacking some arbitrary features in
> > some other languages. The above examples are, basically, "it's too
> > complex", "it's not complex enough", "it's too complex", "it's not
> > complex enough".
> 
> I have zero interest in defending the article in question.  But WRT
> "too complex", consider the following.  C++ has an exception
> mechanism.  C provided <signal.h> to handle certain exceptions, which
> C++ renamed and kept. Can't you see how providing two methods to do
> one thing is more complex than providing one method?  This has
> nothing at all to do with whether the approach used to develop C++
> was necessary and proper.  It has to solely to do with the end result.

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.

Chris

[toc] | [prev] | [next] | [standalone]

#30088

"Chris Vine" wrote:

"Osmium" <r124c4u102@comcast.net> wrote:
> "Juha Nieminen" wrote:
>
> > The above are a good example of completely inconsistent logic. He
> > both decries the language being "too complex", and at the same time
> > that it isn't complex enough, lacking some arbitrary features in
> > some other languages. The above examples are, basically, "it's too
> > complex", "it's not complex enough", "it's too complex", "it's not
> > complex enough".
>
> I have zero interest in defending the article in question.  But WRT
> "too complex", consider the following.  C++ has an exception
> mechanism.  C provided <signal.h> to handle certain exceptions, which
> C++ renamed and kept. Can't you see how providing two methods to do
> one thing is more complex than providing one method?  This has
> nothing at all to do with whether the approach used to develop C++
> was necessary and proper.  It has to solely to do with the end result.

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.

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.

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

I know nothing at all of Ada but one of my first steps would be to contact 
someone fluent in Ada to see how they handled the general problem.

[toc] | [prev] | [next] | [standalone]

#30091

Op 24-Jul-14 19:28, Osmium schreef:
> 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?

The reason is that one of the design goals of C++ is to be (mostly) 
backwards compatible with existing C code. If setjmp() and longjmp() 
were removed, or printf() or the entire <stdio.h> were removed, many C 
programs would fail to compile on a C++ compiler.

I believe the backwards compatibility with C is one of C++ major 
strengths but also its major weakness. If they were to design a 
programming language from scratch with the same objectives as C++ but 
without backwards compatibility, I expect the result would be a much 
cleaner programming language.

[toc] | [prev] | [next] | [standalone]

#30095

Dombo <dombo@disposable.invalid> wrote:
> The reason is that one of the design goals of C++ is to be (mostly) 
> backwards compatible with existing C code. If setjmp() and longjmp() 
> were removed, or printf() or the entire <stdio.h> were removed, many C 
> programs would fail to compile on a C++ compiler.

The advantage of compatibility with C isn't really that you can take
a C program and compile it with a C++ compiler. The major advantage
of this is that you can use C libraries directly from C++ code.

Let's face it: Probably at least 99% of libraries out there that
can be used in C++ are in C. Only a small minority hare made in C++.
There's an enormous advantage in being able to use them in C++ as well.
(It's also an advantage that if you are making a library, you can
make it such that it can be used as-is in C and C++ programs, even
as a precompiled library.)

Good examples of this are libraries like zlib and pnglib.

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#30107

On Fri, 2014-07-25, Juha Nieminen wrote:
> Dombo <dombo@disposable.invalid> wrote:
>> The reason is that one of the design goals of C++ is to be (mostly) 
>> backwards compatible with existing C code. If setjmp() and longjmp() 
>> were removed, or printf() or the entire <stdio.h> were removed, many C 
>> programs would fail to compile on a C++ compiler.
>
> The advantage of compatibility with C isn't really that you can take
> a C program and compile it with a C++ compiler. The major advantage
> of this is that you can use C libraries directly from C++ code.

That's part of it ... as a C++ programmer you work in the same
ecosystem as the C programmers.  You have access to the same resources
-- libraries, but also example source, books, web resources, tools ...
and so on.  You can live in /their/ world, but you have an edge.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#30093

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

[toc] | [prev] | [next] | [standalone]

#30094

On Thu, 24 Jul 2014 23:29:02 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
[snip]
> 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.

Ah, I now see that you were asking why _C++_ retains setjmp() and
longjmp()?  Presumably for C compatibility.  And so that C++ code can
interface with a C library which happens to use longjmp() (and yes I
have used one).  The C++ requirement is that you comply with §18.10/4
of the standard, which is tedious but doable.

Chris

[toc] | [prev] | [next] | [standalone]

#30101

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
>On Thu, 24 Jul 2014 23:29:02 +0100
>Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>[snip]
>> 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.
>
>Ah, I now see that you were asking why _C++_ retains setjmp() and
>longjmp()?  Presumably for C compatibility.  And so that C++ code can
>interface with a C library which happens to use longjmp() (and yes I
>have used one).  The C++ requirement is that you comply with =A718.10/4
>of the standard, which is tedious but doable.

Realize that C++ didn't originally have exceptions, thus setjmp/longjmp
were the only way provide similar capabilities.   Exceptions were added
in 3.0, IIRC.

There are still codebases being maintained using C++ 2.1 feature sets
(no templates, no exceptions, no rtti).

I still use sigsetjmp/siglongjmp in C++ applications when useful. Also in
C++-based operating systems and hypervisors (although one really needs to roll ones
own setjmp implementation then, due to the lack of any run-time libraries).  I
also use sigsetjmp/siglongjmp in applications where the overhead of
standard C++ exception unwinding is costly (processor simulators, for example).

From one of the C++ hypervisors:

/**
 * Allow a core to roll-back to a preserved state.   Operates much
 * like traditional setjmp/longjmp.   Provides for a callback function
 * that will be invoked if the state is rolled-back.
 */
class c_rollback {
    /**
     * Preserve the set of "callee-preserved" registers plus the current
     * stack pointer and instruction pointer.   Note that the order of
     * these is relied upon by the _setjmp and _longjmp assembler routines!
     */
    struct _rb_state {
        uint64  s_rbx;      // 0
        uint64  s_rbp;      // 8
        uint64  s_r12;      // 16
        uint64  s_r13;      // 24
        uint64  s_r14;      // 32
        uint64  s_r15;      // 40
        uint64  s_rip;      // 48
        uint64  s_rsp;      // 56
    } rb_state;

    static   uint64 _setjmp(_rb_state *);
    static   void   _longjmp(_rb_state *, uint64);
public:

    void    save(c_rollback_handler *) __attribute__((always_inline));
    void    restore(uint64);
};

/**
 * Save the state of the current core, such that it can be
 * restored with a corresponding call to the c_rollback::push
 * function.   This must always be inlined for the stack above the
 * stack pointer to be correct.
 *
 * @param hp   A handler to be invoked if the pop function is called, or
 *             the value NULL if the caller doesn't require notification.
 */
inline void
c_rollback::save(c_rollback_handler *hp)
{
    uint64 rval;

    rval = _setjmp(&rb_state);
    if (rval != 0) {
        if (hp != NULL) {
            hp->rollback(rval);
        }
    }
}

/**
 * Restore the state of the current core to the most recent
 * rollback state saved.   This will result in the rollback handler
 * provided to the ::push function to be invoked.
 */
inline void
c_rollback::restore(uint64 rval)
{
    _longjmp(&rb_state, rval);

    /* NOTREACHED */
}

/**
 * Preserve the current register state.   This function is only for the use
 * of c_rollback.
 *
 *  On entry:
 *    %rdi    c_rollback::_rb_state *
 */
ENTRY(_ZN10c_rollback7_setjmpEPNS_9_rb_stateE)
        pop     %rsi                    # Get return address & adjust stack
        xorl    %eax, %eax              # Processor will zero-extend to 64 bits
        movq    %rbx, (%rdi)            # Save RBX register
        movq    %rsp, 56(%rdi)          # Save RSP after return
        push    %rsi                    # Restore return address
        movq    %rbp, 8(%rdi)           # Save RBP
        movq    %r12, 16(%rdi)          # Save R12
        movq    %r13, 24(%rdi)          # Save R13
        movq    %r14, 32(%rdi)          # Save R14
        movq    %r15, 40(%rdi)          # Save R15
        movq    %rsi, 48(%rdi)          # Save Return Address
        ret

/**
 * Restore current register state.   This function is only for the use
 * of c_rollback.
 *
 * On entry:
 *   %rdi    c_rollback::_rb_state *
 *   %rsi    uint64
 */
ENTRY(_ZN10c_rollback8_longjmpEPNS_9_rb_stateEm)
        movq    %rsi, %rax              # Return value
        movq    (%rdi), %rbx            # Restore RBX
        movq    8(%rdi), %rbp           # Restore RBP
        movq    16(%rdi), %r12          # Restore R12
        movq    24(%rdi), %r13          # Restore R13
        movq    32(%rdi), %r14          # Restore R14
        movq    40(%rdi), %r15          # Restore R15
        movq    56(%rdi), %rsp          # Restore RSP
        jmp    *48(%rdi)

[toc] | [prev] | [next] | [standalone]

#30213

Scott Lurndal <scott@slp53.sl.home> wrote:
> Exceptions were added in 3.0, IIRC.

3.0? WTF?

> I still use sigsetjmp/siglongjmp in C++ applications when useful.

Sure, if you want to bypass destructors...

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#30217

Juha Nieminen <nospam@thanks.invalid> writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>> Exceptions were added in 3.0, IIRC.
>
>3.0? WTF?

There were no exceptions in (cfront) 2.1, it was around 3.0 that
templates showed up, and exceptions as well[*].  

[*] Support for both  had been added, but marked experimental and it didn't
    work at all for any real application and when it did work, was
    inefficient as all get-out.

 http://www.softwarepreservation.org/projects/c_plus_plus/cfront/release_2.0/doc/ProductReferenceManual.pdf

>
>> I still use sigsetjmp/siglongjmp in C++ applications when useful.
>
>Sure, if you want to bypass destructors...

  Obviously. Duh, that's something anyone who chooses to use setjmp/longjmp
needs to be aware of.

  The applications which use sigsetjmp/siglongjmp tend to create long-lived
objects using new and delete, and control the allocation and deallocation
carefully.

[toc] | [prev] | [next] | [standalone]

#30221

Scott Lurndal <scott@slp53.sl.home> wrote:
>>> I still use sigsetjmp/siglongjmp in C++ applications when useful.
>>
>>Sure, if you want to bypass destructors...
> 
>  Obviously. Duh, that's something anyone who chooses to use setjmp/longjmp
> needs to be aware of.
> 
>  The applications which use sigsetjmp/siglongjmp tend to create long-lived
> objects using new and delete, and control the allocation and deallocation
> carefully.

How about not using those functions at all? The vast majority of people
manage just fine without them.

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#30222

On Tuesday, 5 August 2014 09:57:01 UTC+3, Juha Nieminen  wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
> >>> I still use sigsetjmp/siglongjmp in C++ applications when useful.
> >>
> >>Sure, if you want to bypass destructors...
> > 
> >  Obviously. Duh, that's something anyone who chooses to use setjmp/longjmp
> > needs to be aware of.
> > 
> >  The applications which use sigsetjmp/siglongjmp tend to create long-lived
> > objects using new and delete, and control the allocation and deallocation
> > carefully.
> 
> How about not using those functions at all? The vast majority of people
> manage just fine without them.

There may be is C library used that uses those and no budget to invest
into refactoring or translating that library to C++.

Otherwise there are lot of C library functions usage of what
should not pass review in normal C++ code-base at all.

[toc] | [prev] | [next] | [standalone]

#30223

On Tue, 05 Aug 2014 05:53:17 -0700, Öö Tiib wrote:

> On Tuesday, 5 August 2014 09:57:01 UTC+3, Juha Nieminen  wrote:
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>> >>> I still use sigsetjmp/siglongjmp in C++ applications when useful.
>> >>
>> >>Sure, if you want to bypass destructors...
>> > 
>> >  Obviously. Duh, that's something anyone who chooses to use
>> >  setjmp/longjmp
>> > needs to be aware of.
>> > 
>> >  The applications which use sigsetjmp/siglongjmp tend to create
>> >  long-lived
>> > objects using new and delete, and control the allocation and
>> > deallocation carefully.
>> 
>> How about not using those functions at all? The vast majority of people
>> manage just fine without them.
> 
> There may be is C library used that uses those and no budget to invest
> into refactoring or translating that library to C++.

I would do this only if I really, really have to. And I would think hard 
and long about encapsulating this stuff so it is safe to use from 
"normal" C++.

M4

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web