"“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett"

[Lynn McGuire]

"“Rust is the future of systems programming, C is the new Assembly”:
Intel principal engineer, Josh Triplett"

https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/

"At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a
Principal Engineer at Intel gave an insight into what Intel is
contributing to bring the most loved language, Rust to full parity with
C. In his talk titled Intel and Rust: the Future of Systems Programming,
he also spoke about the history of systems programming, how C became the
“default” systems programming language, what features of Rust gives it
an edge over C, and much more."

Lynn

[Melzzzzz]

Rust is nowhere near C. Actually, nowhere near C++. It is nice language,
but not for low level programming. During years they ditched GC and most
of the things that cripples determinism and performance, it is ok, but
without pointer arithmetic and null pointers it is high level language.
Having to convert pointer to int and back in order to perform arithmetic
is worse that doing it in assembler.
But what Rust got it right is error handling, much better than
excpetions. But not having inheritance and forbidding two mutable
references to distinct array elements is stupid. Also no tail recursion
optimisation and no way to disable array checks.


>
> Lynn
>


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[David Brown]

On 29/08/2019 04:36, Melzzzzz wrote:
> On 2019-08-28, Lynn McGuire <lynnmc...@gmail.com> wrote:
>> "“Rust is the future of systems programming, C is the new Assembly”:
>> Intel principal engineer, Josh Triplett"
>>
>> https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/
>>
>> "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a
>> Principal Engineer at Intel gave an insight into what Intel is
>> contributing to bring the most loved language, Rust to full parity with
>> C. In his talk titled Intel and Rust: the Future of Systems Programming,
>> he also spoke about the history of systems programming, how C became the
>> “default” systems programming language, what features of Rust gives it
>> an edge over C, and much more."
>
> Rust is nowhere near C. Actually, nowhere near C++. It is nice language,
> but not for low level programming. During years they ditched GC and most
> of the things that cripples determinism and performance, it is ok, but
> without pointer arithmetic and null pointers it is high level language.
> Having to convert pointer to int and back in order to perform arithmetic
> is worse that doing it in assembler.

That sounds terrible. (I am not very familiar with Rust.)

> But what Rust got it right is error handling, much better than
> excpetions. But not having inheritance and forbidding two mutable
> references to distinct array elements is stupid.

I have worked with a C-like language which had that many of that kind of
restriction (XC for the XMOS microcontrollers, if anyone is curious).
For a lot of code, it can be helpful - it allowed the compiler to find
lots of situations that could be problematic, especially in heavily
threaded and parallel code. But you invariably had situations where the
restrictions were too much - you needed shared access, or whatever, in
cases where you know they are safe. This typically lead to inline
assembly code to get round the safety limitations imposed by the
language and compiler - that was /not/ a good situation!

> Also no tail recursion optimisation and no way to disable array checks.
>

Surely tail recursion optimisation is just a matter of the compiler? C
and C++ don't have any mention of such optimisations in their standards,
but a compiler can do it as long as the code works under the "as if"
rule. Does the same not apply to Rust?

As for array checks, again I would think a compiler could elide a fair
number of them, reducing the cost of having them on all the time.


One thing that I gather Rust does well, that C++ has trouble with, is
that when you do the Rust equivalent of std::move'ing something, any
attempt to use the moved-from object is flagged by the compiler. I
think that would be good to spot in C++.

[BGB]

How about, instead:
We take C;
We add some features to support things like bounds-checked arrays and
similar;
We mostly call it done.


Many past variants of bounds-checked arrays did funky things with the
syntax, which is a problem if one wants to be able to make it work in a
compiler without support for this feature (eg: via non-convoluted use of
defines).

My thought is, say:
_BoundsCheck int *arr;
Which behaves sorta like "int[] arr;" in Java or similar.

Then it is given a shorthand in a header (eg: bounded), which becomes
no-op if the compiler doesn't support it.

Otherwise, it behaves mostly like a normal pointer, apart from potential
runtime bounds checking, and a different internal representation. May
decay into a normal pointer, potentially with a warning.


While at it, something like a standardized header for accessing
misaligned and explicit endianess values would be nice.

eg:
uint32_t getuint32le(void *ptr);
void setint32le(void *ptr, int32_t val);
...
Where: le: little endian, be: big endian, no suffix: native endian.
And, these functions work regardless of alignment.

This being semi-common boilerplate one either needs to copy around or
reimplement fairly often (and for which the optimal way to do these
varies between compilers; and with some dependence on target architecture).


> Lynn
>

[Ian Collins]

On 29/08/2019 21:02, David Brown wrote:
>
> One thing that I gather Rust does well, that C++ has trouble with, is
> that when you do the Rust equivalent of std::move'ing something, any
> attempt to use the moved-from object is flagged by the compiler. I
> think that would be good to spot in C++.

clang-tidy does a pretty good job with "bugprone-use-after-move"
<https://clang.llvm.org/extra/clang-tidy/checks/bugprone-use-after-move.html>

--
Ian.

[David Brown]

Yes, I saw that after googling a bit.

I would have thought, however, that pretty much any use (other than
assignment of some sort) of a named object after it is moved, is likely
to be a bug. And it is therefore something that could be warning about
by default.


#include <memory>

extern int a, b, c;


void foo(void) {
auto p = std::make_unique<int>(3);
a = *p;
auto q = std::move(p);
b = *q;
c = *p;
}


Both clang and gcc are smart enough to move the value 3 directly into
"a" and "b", and if the last line is omitted, they can remove the call
to "new" (at least in their trunk versions). Both are smart enough to
know that "c = *p;" is undefined behaviour here, and generate "ud2"
instructions on x86.

Yet neither compiler warns about this clearly wrong behaviour despite
-Wall -Wextra.

[Ian Collins]

Use a bigger hammer!

$ clang-tidy x.cc

1 warning generated.
/tmp/x.cc:11:9: warning: Dereference of null smart pointer 'p' of type
'std::unique_ptr' [clang-analyzer-cplusplus.Move]
c = *p;
^
/tmp/x.cc:9:14: note: Smart pointer 'p' of type 'std::unique_ptr' is
reset to null when moved from

auto q = std::move(p);

^
/tmp/x.cc:11:9: note: Dereference of null smart pointer 'p' of type
'std::unique_ptr'
c = *p;

--
Ian.

[Bonita Montero]

Rust is nice, but Rust has no exceptions. I wouldn't like to evaluate
this combined error- and return-values after each function-call that
might fail.

[Bonita Montero]

> Rust is nowhere near C. Actually, nowhere near C++. It is nice language,
> but not for low level programming. During years they ditched GC and most

> of the things that cripples determinism and performance, ...


Rust has no GC, but works with counted references.

[Öö Tiib]

On Thursday, 29 August 2019 13:14:29 UTC+3, BGB wrote:
> On 8/28/2019 4:11 PM, Lynn McGuire wrote:
> > "“Rust is the future of systems programming, C is the new Assembly”:
> > Intel principal engineer, Josh Triplett"
> >
> > https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/
> >
> >
> > "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a
> > Principal Engineer at Intel gave an insight into what Intel is
> > contributing to bring the most loved language, Rust to full parity with
> > C. In his talk titled Intel and Rust: the Future of Systems Programming,
> > he also spoke about the history of systems programming, how C became the
> > “default” systems programming language, what features of Rust gives it
> > an edge over C, and much more."
> >
>
> How about, instead:
> We take C;
> We add some features to support things like bounds-checked arrays and
> similar;
> We mostly call it done.

Rust supports lot of interesting safety features (like RAII, smart pointers,
ownership, generics, move semantics, thread safety).
Adding some safe features at side does not help as history with C++ shows.
Result is bigger language with all the unsafe stuff still there and valid.
OTOH if to cripple the unsafe features a bit then result is some kind of
fourth language that is neither C, C++ nor Rust.

[Kenny McCormack]

In article <qk8hrh$ua3$1...@news.albasani.net>,

Why is this posted to CLC? Surely, the comparison is more valid to
C++, given that C++ has things like exceptions and so on. It should have
only been posted to CLC++.

(Or, is there a parallel thread going on in CLC++ - that I am not (yet)
aware of?)

P.S. Of course there will be a blogs and stuff like this one (the one
referred to in the OP) telling us that Rust is the next big thing and
obviously the thing that is going to be just so absolutely neato keeno that
you'll be unable to imagine how we ever got along with it. This is true
for any new programming language.

Look at it this way: If a new programming language came out and there was
no blog post (or whatever) telling us with absolute authority that this is
the absolute greatest thing since, well, ever - that language will have
zero, zip, nada chance of ever being used by anyone.

--
Pensacola - the thinking man's drink.

[Bonita Montero]

>> Rust is nice, but Rust has no exceptions. I wouldn't like to evaluate
>> this combined error- and return-values after each function-call that
>> might fail.

> Why is this posted to CLC? ...

Why do you post another Follow-Up there if you consider this as
inadequate.

[David Brown]

I might well do that. But it won't stop me wanting the feature in the
tools I already use.

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
> On 29/08/2019 04:36, Melzzzzz wrote:

[...]

>> Rust is nowhere near C. Actually, nowhere near C++. It is nice language,
>> but not for low level programming. During years they ditched GC and most
>> of the things that cripples determinism and performance, it is ok, but
>> without pointer arithmetic and null pointers it is high level language.
>> Having to convert pointer to int and back in order to perform arithmetic
>> is worse that doing it in assembler.
>
> That sounds terrible. (I am not very familiar with Rust.)

What's terrible about it? Rust doesn't particularly need pointer
arithmetic; unlike C, it's array indexing isn't defined in terms of
pointers.

[...]

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[Mel]

On Thu, 29 Aug 2019 11:02:30 +0200, David Brown
<david...@hesbynett.no> wrote:
> One thing that I gather Rust does well, that C++ has trouble with,
is
> that when you do the Rust equivalent of std::move'ing something, any
> attempt to use the moved-from object is flagged by the compiler. I
> think that would be good to spot in C++.

Rust move is built into language. Moved objects destructor is not
called.

--
Press any key to continue or any other to quit

[Mel]

On Thu, 29 Aug 2019 13:29:11 -0700, Keith Thompson <ks...@mib.org>
wrote:

> David Brown <david...@hesbynett.no> writes:
> > On 29/08/2019 04:36, Melzzzzz wrote:
> [...]
> >> Rust is nowhere near C. Actually, nowhere near C++. It is nice
language,
> >> but not for low level programming. During years they ditched GC
and most
> >> of the things that cripples determinism and performance, it is
ok, but
> >> without pointer arithmetic and null pointers it is high level
language.
> >> Having to convert pointer to int and back in order to perform
arithmetic
> >> is worse that doing it in assembler.
> >
> > That sounds terrible. (I am not very familiar with Rust.)


> What's terrible about it? Rust doesn't particularly need pointer
> arithmetic; unlike C, it's array indexing isn't defined in terms of
> pointers.

You need pointers for low level things. In rust you need unsafe
blocks for almost anything.

--
Press any key to continue or any other to quit

[Mel]

Yes, but it is not much used. Box, owned reference is built in, i
zhink that rc is not built in

--
Press any key to continue or any other to quit

[Mel]

On Thu, 29 Aug 2019 06:08:13 -0700 (PDT), Öö Tiib<oot...@hot.ee>
wrote:

> On Thursday, 29 August 2019 13:14:29 UTC+3, BGB wrote:
> > On 8/28/2019 4:11 PM, Lynn McGuire wrote:

> > > "“Rust is the future of systems programming, C is the new Assem=

> bly”:
> > > Intel principal engineer, Josh Triplett"
> > >
> > >
https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is

=

> -the-new-assembly-intel-principal-engineer-josh-triplett/
> > >
> > >
> > > "At Open Source Technology Summit (OSTS) 2019, Josh Triplett, a
> > > Principal Engineer at Intel gave an insight into what Intel is
> > > contributing to bring the most loved language, Rust to full

parity with=

> > > C. In his talk titled Intel and Rust: the Future of Systems

Programming=

> ,
> > > he also spoke about the history of systems programming, how C

became th=
> e
> > > “default” systems programming language, what features o=

> f Rust gives it
> > > an edge over C, and much more."
> > >
> >
> > How about, instead:
> > We take C;
> > We add some features to support things like bounds-checked arrays
and
> > similar;
> > We mostly call it done.


> Rust supports lot of interesting safety features (like RAII, smart

pointers=

> ,
> ownership, generics, move semantics, thread safety).
> Adding some safe features at side does not help as history with C++
shows.
> Result is bigger language with all the unsafe stuff still there and
valid.
> OTOH if to cripple the unsafe features a bit then result is some
kind of
> fourth language that is neither C, C++ nor Rust.

Rust generics are interface based. You cant do anything with generic
type unless you tell which interfaces satisfies.

[Keith Thompson]

Mel <m...@zzzzz.com> writes:
> On Thu, 29 Aug 2019 13:29:11 -0700, Keith Thompson <ks...@mib.org>
> wrote:
>> David Brown <david...@hesbynett.no> writes:
>> > On 29/08/2019 04:36, Melzzzzz wrote:
>> [...]
>> >> Rust is nowhere near C. Actually, nowhere near C++. It is nice
>> >> language, but not for low level programming. During years they
>> >> ditched GC and most of the things that cripples determinism and
>> >> performance, it is ok, but without pointer arithmetic and null
>> >> pointers it is high level language. Having to convert pointer to
>> >> int and back in order to perform arithmetic is worse that doing it
>> >> in assembler.
>> >
>> > That sounds terrible. (I am not very familiar with Rust.)
>
>> What's terrible about it? Rust doesn't particularly need pointer
>> arithmetic; unlike C, it's array indexing isn't defined in terms of
>> pointers.
>
> You need pointers for low level things.

You need pointer *arithmetic* for far fewer things than you need
pointers for.

> In rust you need unsafe
> blocks for almost anything.

So use unsafe blocks.

[Mel]

That's Rust advantage. Returnig discriminated union is right way for
handling errors. Rust has syntactic sugar in that. Latest proposal
for c++ exceptions leans toeard that solution.

[Bonita Montero]

> Returnig discriminated union is right way for handling errors.

NO, that's a mess. Exceptions are by far more comfortable.
The best variant are the distinction between checked and
unchecked exceptions in Java.

[Bonita Montero]

And exceptions are more performant for the performance-relevant case
that no exception is thrown with table-driven excepion-handling. The
code-path that is processed when no exception is thrown is almost as
efficient as if there isn't any exception-handling (nearly zero-over-
head).

[Öö Tiib]

On Friday, 30 August 2019 09:11:01 UTC+3, Mel wrote:
> On Thu, 29 Aug 2019 06:08:13 -0700 (PDT), Öö Tiib<oot...@hot.ee>
> wrote:
>
> > Rust supports lot of interesting safety features (like RAII, smart

> > pointers, ownership, generics, move semantics, thread safety).

> > Adding some safe features at side does not help as history with
> > C++ shows.
> > Result is bigger language with all the unsafe stuff still there and
> > valid.
> > OTOH if to cripple the unsafe features a bit then result is some
> > kind of fourth language that is neither C, C++ nor Rust.
>
> Rust generics are interface based. You cant do anything with
> generic type unless you tell which interfaces satisfies.

Perhaps I don't understand what you mean. Can you bring example?
The main point of generics seems to work in Rust about like in C++
templates. There are generic functions, data types and methods.
Instantiations of these work like concrete functions, data types and
methods.
It is more clear, efficient and/or type-safe than what can be done
in C.
Type erasure through "void*" or "..." function parameters is type-
unsafe and can be inefficient. Code generated with preprocessor
can be type safe and efficient but might have unneeded verbosity
in interface or to be hard to debug. So it is often better to have
copy-paste code in C.

[Mel]

Exceptions take space or time, there is no escape, and they are non
deterministic...

[David Brown]

On 29/08/2019 22:29, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
>> On 29/08/2019 04:36, Melzzzzz wrote:
> [...]
>>> Rust is nowhere near C. Actually, nowhere near C++. It is nice language,
>>> but not for low level programming. During years they ditched GC and most
>>> of the things that cripples determinism and performance, it is ok, but
>>> without pointer arithmetic and null pointers it is high level language.
>>> Having to convert pointer to int and back in order to perform arithmetic
>>> is worse that doing it in assembler.
>>
>> That sounds terrible. (I am not very familiar with Rust.)
>
> What's terrible about it? Rust doesn't particularly need pointer
> arithmetic; unlike C, it's array indexing isn't defined in terms of
> pointers.
>

(Again, let me note that I know little about Rust - I've read some
stuff, but never used it. So if I get things wrong about it, I hope to
be corrected.)

As you say in your other post, pointer arithmetic isn't actually used
that much in C or C++, once you discount array access and iterators
which would be handled in a more "high level" manner in a non-C language.

But sometimes - even if it is only occasionally - it /is/ useful. This
can be especially true in low-level and systems code, which apparently
is a target for Rust.

The whole idea of Rust is to be "safer" than C - it aims to turn logical
errors such as misuse of pointers, confusion about owners, etc., into
compiler errors. That is a great ambition. But to work properly, you
have to follow the rules - workarounds that go outside those rules
should be as limited as possible, and strongly discouraged if they can't
be blocked by tools.

The language seems to be saying "We guarantee your code will avoid null
pointer dereferences, buffer overflows, use after free, memory leaks,
and all the pointer-related problems that plague C programmers." So
far, so good. Then it says "We realise that is too limiting sometimes,
so here are the ways to cheat, hack, and mess about under the hood".
Your guarantees are out the window, and you are back to /exactly/ the
same situation as you have in C - design carefully, code carefully to
keep your code safe, because the language and tools won't do it for you.


So it is not so much the idea of doing pointer arithmetic manually as
integer arithmetic that concerns me (though it might be a step lower
level than C's pointer arithmetic). It is the idea that the language
allows it and that it is considered an acceptable solution that bothers me.

[Mel]

On Fri, 30 Aug 2019 01:00:48 -0700 (PDT), Öö Tiib<oot...@hot.ee>
wrote:

> > Rust generics are interface based. You cant do anything with
> > generic type unless you tell which interfaces satisfies.




> Perhaps I don't understand what you mean. Can you bring example?
> The main point of generics seems to work in Rust about like in C++

Not even close. Imagin that you have to cite what abstract base
classes tvpe inherits, and only thing you can do with type is trough
interface...

[Bonita Montero]

>> And exceptions are more performant for the performance-relevant case
>> that no exception is thrown with table-driven excepion-handling. The
>> code-path that is processed when no exception is thrown is almost as
>> efficient as if there isn't any exception-handling (nearly
> zero-over-
>> head).

> Exceptions take space or time, there is no escape, and they are non
> deterministic...

Computers are always deterministic. ;-)
But trowing exceptions is slow. But the case when we have a resouce-
or I/O-collapse isn't performance-relevant, i.e. it doesn't matter
if throwsing an exception lasts 10 or 1.000 clock-cycles.

[Öö Tiib]

The examples in documentation ...
<https://doc.rust-lang.org/book/ch10-00-generics.html>
... are like that:

// generic type
struct Point<T> {
x: T,
y: T,
}
// generic method of generic type
impl<T> Point<T> {
fn x(&self) -> &T {
&self.x
}
}
// usage
fn main() {
let p = Point { x: 5, y: 10 };

println!("p.x = {}", p.x());
}

That does not seem to fit with what you describe.

[Mel]

I am not talking when you throw.

[Mel]

On Fri, 30 Aug 2019 01:26:49 -0700 (PDT), Öö Tiib<oot...@hot.ee>

wrote:
> On Friday, 30 August 2019 11:16:32 UTC+3, Mel wrote:

> > On Fri, 30 Aug 2019 01:00:48 -0700 (PDT), Öö Tiib<oot...@hot.ee=

Try to do something with x...

[Bonita Montero]

>> Computers are always deterministic. ;-)
>> But trowing exceptions is slow. But the case when we have a resouce-
>> or I/O-collapse isn't performance-relevant, i.e. it doesn't matter
>> if throwsing an exception lasts 10 or 1.000 clock-cycles.

> I am not talking when you throw.

The non-throw-case takes almost no or no performance.
Evaluating return-codes is simply a magnitude slower.

[Mel]

On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero
<Bonita....@gmail.com> wrote:
> >> Computers are always deterministic. ;-)
> >> But trowing exceptions is slow. But the case when we have a
resouce-
> >> or I/O-collapse isn't performance-relevant, i.e. it doesn't
matter
> >> if throwsing an exception lasts 10 or 1.000 clock-cycles.


> > I am not talking when you throw.


> The non-throw-case takes almost no or no performance.

That's no true. You have to install handlers evrry time or prepare
tbla for each function at program start...

> Evaluating return-codes is simply a magnitude slower.

This is especially not true.

[Bonita Montero]

>> Evaluating return-codes is simply a magnitude slower.

> This is especially not true.

No, this is true.
You don't simply unterstand the implications of table-driven
exception handling or table-driven exception-handling at all.

[David Brown]

On 30/08/2019 10:47, Bonita Montero wrote:
>>> Evaluating return-codes is simply a magnitude slower.
>
>> This is especially not true.
>
> No, this is true.

I take it you have measured this yourself? You have sample code,
measurements, statistics to back up this very specific claim?

Or is it just based on "something you read somewhere", repeated in the
hope that people will believe you more the second time?

> You don't simply unterstand the implications of table-driven
> exception handling or table-driven exception-handling at all.

I expect Mel does understand it. I am less convinced /you/ do.


Different error handling techniques have their pros and cons. Anyone
claiming one method is faster, safer, clearer, easier than other methods
is guaranteed to be /wrong/. They will have different balances, and
there is no solution that is the "best" in all situations, or the best
in all ways.

Table-driven exception handling tends to be efficient at run-time when
exceptions are not thrown, when you are running on larger processors
(like x86), and when you have no issues with code space. That makes it
a good choice (from the efficiency viewpoint) on PC programming.

But you can also find that the possibility of exceptions passing through
functions can affect their efficiency, even if they don't throw or
catching anything directly - it can affect ordering and optimisation of
the code by the compiler. It can affect the re-use of stack slots as
the compiler has to track all possible exception points and be able to
unwind correctly.

On resource-constrainted systems, this kind of thing can lead to unwind
tables that are bigger than the actual code size - a horrible level of
inefficiency that is unacceptable in many cases.

And while table-driven exception handling does not need extra
instruction codes (just data tables) for functions that pass on
exceptions without handling them, you need plenty of extra code - and
run-time - when throwing the exception, or when catching it.


Error handling via return codes, on the other hand, uses minimal extra
code space in functions that raise or handle the errors - usually less
overhead than for throwing or catching exceptions. It is certainly
going to be much faster when errors do occur. But you have to have some
way of passing on errors in functions between the "thrower" and the
"catcher". That means more explicit source code, but more efficient
object code.


Each technique has, as I said, its pros and cons. And there are lots of
reasons why one might pick one method over the other beyond efficiency -
do you want your error handling clear and explicit, or automatic and
hidden? Which is easier to get right, and which is harder to get wrong?


But one thing we can be sure of - Sutter would not have started the
process of getting "Zero-overhead deterministic exceptions" into C++ if
current C++ exceptions were as ideal as suggested. And while Sutter's
ideas here may come to naught, and he can be as wrong as anyone else, I
am more inclined to listen to his thoughts than those of Bonita.

[Bonita Montero]

> I expect Mel does understand it. I am less convinced /you/ do.

Disassemble the code that calls a fuction that might throw an exceptions
with an without enabled EH. The difference is only, that the optimiza-
tions around that call might be slightly weakened; that's all. But that
usually doesn't outweigh the overhead against manually evaluating
return-codes.

> Different error handling techniques have their pros and cons. Anyone
> claiming one method is faster, safer, clearer, easier than other methods
> is guaranteed to be /wrong/.

1. Table-driven EH is usually faster.
2. I didn't say that it is safer or clearer,
but it is much more convenient.
3. When you come to the excepion-handling mechanism like in Java
with checked and unchecked exceptions, you get the best solution.
But for compatibility-reasons with C this isn't possible in C++.

> Table-driven exception handling tends to be efficient at run-time when
> exceptions are not thrown, when you are running on larger processors
> (like x86), and when you have no issues with code space. That makes it
> a good choice (from the efficiency viewpoint) on PC programming.

Almost right, but it doesn't depend on the performance of the CPU.
Even on small CPUs the performance of processing a resurce- or I/O
-collapse doesn't count.

> But you can also find that the possibility of exceptions passing through
> functions can affect their efficiency, even if they don't throw or
> catching anything directly - it can affect ordering and optimisation of
> the code by the compiler. It can affect the re-use of stack slots as
> the compiler has to track all possible exception points and be able to
> unwind correctly.

The loss of optimization-opportunities with table-driven exception
-handling is very slight. And the cost is of course not so high as
handling return-codes manually.

> On resource-constrainted systems, this kind of thing can lead to unwind
> tables that are bigger than the actual code size - a horrible level of
> inefficiency that is unacceptable in many cases.

That's true, but then you wouldn't use C++.

> Error handling via return codes, on the other hand, uses minimal extra
> code space in functions that raise or handle the errors - usually less
> overhead than for throwing or catching exceptions.

1. This case isn't performance relevant.
2. Yo cannot say that this is always true. The thing is simply that
there might be a number of return-codes evaluated at each call-level
which might result in a higher total CPU-time.

[David Brown]

On 30/08/2019 11:56, Bonita Montero wrote:
>> I expect Mel does understand it.  I am less convinced /you/ do.
>
> Disassemble the code that calls a fuction that might throw an exceptions
> with an without enabled EH. The difference is only, that the optimiza-
> tions around that call might be slightly weakened; that's all. But that
> usually doesn't outweigh the overhead against manually evaluating
> return-codes.

There is no doubt that exceptions are aimed at having minimal run-time
cost when they are not thrown. But it is important to realise that
/minimal/ is not /zero/.

>
>> Different error handling techniques have their pros and cons.  Anyone
>> claiming one method is faster, safer, clearer, easier than other methods
>> is guaranteed to be /wrong/.
>
> 1. Table-driven EH is usually faster.

Usually it is faster when exceptions are not thrown, but a lot slower
when they /are/ thrown. But "usually" is not "always". And for some
situations, it is the worst case performance - the speed when there is a
problem - that is critical.

I'm happy with a claim "Table driven exceptions are generally faster,
when there are no errors, than other handling techniques for typical
code on PC's". What I am /not/ happy with is "Exception handling is
faster than other error return techniques".

> 2. I didn't say that it is safer or clearer,
>    but it is much more convenient.

Fair enough - though convenience is also a subjective matter.

> 3. When you come to the excepion-handling mechanism like in Java
>    with checked and unchecked exceptions, you get the best solution.
>    But for compatibility-reasons with C this isn't possible in C++.

Checked exceptions - where the type of exceptions that a function may
throw or pass on is part of the signature - are safer, clearer and more
efficient. (Compilers can use tables or code branches, whichever is
most convenient). But they involve more explicit information, which
some people like and others dislike. And they can't pass through
functions compiled without knowledge of the exceptions - such as C
functions compiled by a C compiler.

>
>> Table-driven exception handling tends to be efficient at run-time when
>> exceptions are not thrown, when you are running on larger processors
>> (like x86), and when you have no issues with code space.  That makes it
>> a good choice (from the efficiency viewpoint) on PC programming.
>
> Almost right, but it doesn't depend on the performance of the CPU.
> Even on small CPUs the performance of processing a resurce- or I/O
> -collapse doesn't count.

Incorrect.

Performance under the worst case is often a critical feature of high
reliability systems. It is precisely because the performance exception
handling is difficult to predict or measure that exceptions are banned
in most such systems.

>
>> But you can also find that the possibility of exceptions passing through
>> functions can affect their efficiency, even if they don't throw or
>> catching anything directly - it can affect ordering and optimisation of
>> the code by the compiler.  It can affect the re-use of stack slots as
>> the compiler has to track all possible exception points and be able to
>> unwind correctly.
>
> The loss of optimization-opportunities with table-driven exception
> -handling is very slight. And the cost is of course not so high as
> handling return-codes manually.
>

That may often be the case, but I would be very wary of generalising too
much.

>> On resource-constrainted systems, this kind of thing can lead to unwind
>> tables that are bigger than the actual code size - a horrible level of
>> inefficiency that is unacceptable in many cases.
>
> That's true, but then you wouldn't use C++.
>

Nonsense. There are many good reasons to use C++, and many features
that can be used, without leading to any inefficiency or bloat.

>> Error handling via return codes, on the other hand, uses minimal extra
>> code space in functions that raise or handle the errors - usually less
>> overhead than for throwing or catching exceptions.
>
> 1. This case isn't performance relevant.

Often not - but you are wrong to generalise like that. And you can
equally well argue that since exception handling is often used in cases
where you are dealing with I/O, the performance cost of manual return
code checks is negligible and therefore irrelevant with such code.

> 2. Yo cannot say that this is always true. The thing is simply that
>    there might be a number of return-codes evaluated at each call-level
>    which might result in a higher total CPU-time.
>

Yes, I have already mentioned that return code checking usually involves
some handling at functions along the chain between the "thrower" and the
"catcher".

[Paavo Helde]

On 30.08.2019 11:43, Mel wrote:
> On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero

>> The non-throw-case takes almost no or no performance.
>
> That's no true. You have to install handlers evrry time or prepare tbla
> for each function at program start...

>> Evaluating return-codes is simply a magnitude slower.
>
> This is especially not true.

Your information is out of date for a couple of decades. The current C++
compilers have implemented zero cost exceptions (in the no-throw path)
already long time ago.

[Mel]

That's simply impossible.

[Bonita Montero]

> Usually it is faster when exceptions are not thrown, but a lot slower
> when they /are/ thrown. But "usually" is not "always". And for some
> situations, it is the worst case performance - the speed when there is a
> problem - that is critical.

The case when an exception is thrown isn't performance-relevant
as this occurs when there's an resource- or I/O-collapse.

> Fair enough - though convenience is also a subjective matter.

That's rather not subjective here because evaluating return-codes on
every call-level is a lot of work.

>> 3. When you come to the excepion-handling mechanism like in Java
>>    with checked and unchecked exceptions, you get the best solution.
>>    But for compatibility-reasons with C this isn't possible in C++.

> Checked exceptions - where the type of exceptions that a function may
> throw or pass on is part of the signature - are safer, clearer and more
> efficient. (Compilers can use tables or code branches, whichever is
> most convenient). But they involve more explicit information, which
> some people like and others dislike. And they can't pass through
> functions compiled without knowledge of the exceptions - such as C
> functions compiled by a C compiler.

Can you read what I told above?

>> Almost right, but it doesn't depend on the performance of the CPU.
>> Even on small CPUs the performance of processing a resurce- or I/O
>> -collapse doesn't count.

> Incorrect.

No, correct.

> Performance under the worst case is often a critical feature of high
> reliability systems.

When you have a resource or I/O-collapse, you don't have reliability
anyway.

>> That's true, but then you wouldn't use C++.

> Nonsense. There are many good reasons to use C++, and many features
> that can be used, without leading to any inefficiency or bloat.

Almost the whole standard-libary uses an allocaor which might
throw bad_alloc; not to use the standard-library isn't really C++.

[Bonita Montero]

> That's simply impossible.

If I wouldn't know how it is possible I would think the same.

[Paavo Helde]

See e.g. http://www.ut.sco.com/developers/products/ehopt.pdf

From that paper:

"Most high-performance EH implementations use the commonly known
table-driven approach. The goal of this approach is to present zero
execution-time overhead, until and unless an exception is thrown."

The paper acknowledges some deficiencies with this goal, mainly missing
some optimization opportunities, then goes further to solve a part of them.

Note this paper is from 1998. The compiler technology has moved forward
meanwhile.

It might be there is some minimal machine code needed for EH like a
register load at function entrance. This does not make it non-zero cost
because the alternative is to use an error return, which would also be
at least a register load plus a branching instruction for checking it in
the caller.

[Bonita Montero]

> Note this paper is from 1998. The compiler technology
> has moved forward meanwhile.

That this is from 1998 doesn't mean that it is relevant to each imple-
mentation. Win32 had structured exception handling from the beginning
with NT 3.1. And the exception-handling-implementation of the first
Visual C++ version was built on top of that. So Microsoft hadn't any
choice to revert that for newer version of VC++.

[Öö Tiib]

But it seemingly did.
Do you mean where I need traits? Like in:

impl<T: Display + PartialOrd> Point<T> {
fn cmp_display(&self) {
if self.x >= self.y { //< here I need PartialOrd
// here I need Display
println!("The largest member is x = {}", self.x);
} else {
println!("The largest member is y = {}", self.y);
}
}
}

That seems Ok type-safety feature.

[Mel]

On Fri, 30 Aug 2019 15:18:21 +0300, Paavo Helde

I already said 'space or time'

[Mel]

Under windows there is run tme cost because of that...

[Mel]

On Fri, 30 Aug 2019 06:30:30 -0700 (PDT), Öö Tiib<oot...@hot.ee>

wrote:
> On Friday, 30 August 2019 11:33:36 UTC+3, Mel wrote:

> > On Fri, 30 Aug 2019 01:26:49 -0700 (PDT), Öö Tiib<oot...@hot.ee=

> >
> > wrote:
> > > On Friday, 30 August 2019 11:16:32 UTC+3, Mel wrote:

> > > > On Fri, 30 Aug 2019 01:00:48 -0700 (PDT), Öö Tiib<ootiib@ho=

No it just returned value. Don't try to win argument when you don't
have any...

> Do you mean where I need traits? Like in:

You always need traits even to initialize value...

> That seems Ok type-safety feature.

It is not safety feature it is how gemerics are implemented in rust.
Same way it works in Haskell.

[Bonita Montero]

>> That this is from 1998 doesn't mean that it is relevant to each

>> implementation. Win32 had structured exception handling from the

>> beginning with NT 3.1. And the exception-handling-implementation
>> of the first Visual C++ version was built on top of that. So
>> Microsoft hadn't any choice to revert that for newer version
>> of VC++.

> Under windows there is run tme cost because of that...

No, structured exception handling an the C++ Eh built on top of that
installs unwind-handleres linked through the stack on each call-level
that needs special unwind-semantics.
With the x64-Windows SEH was re-defined table-driven so that both SEH
and C++-EH have an almost-zero-overhead.

[Melzzzzz]

Zero *run time* overhead at the cost of *space* overhead.


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Öö Tiib]

I did not try to win argument, I admit I have none and I just did
not understand your argument (may be I still don't).

> > Do you mean where I need traits? Like in:
>
> You always need traits even to initialize value...

It is Ok I suppose. Writing those "std::enable_if"s for C++<=17
templates is most tedious and ugly.

> > That seems Ok type-safety feature.
>
> It is not safety feature it is how gemerics are implemented in rust.
> Same way it works in Haskell.

It feels similar to required upcoming concepts/constraints of C++20.

[Melzzzzz]

Well, C++ template types are structural and Rust nominative.
That is whole difference.

[Bonita Montero]

>> No, structured exception handling an the C++ Eh built on top of that
>> installs unwind-handleres linked through the stack on each call-level
>> that needs special unwind-semantics.
>> With the x64-Windows SEH was re-defined table-driven so that both SEH
>> and C++-EH have an almost-zero-overhead.

> Zero *run time* overhead at the cost of *space* overhead.

We're talking abot Windows-computers and not Ardino Unos.

[Bonita Montero]

>> press any key to continue or any other to quit...
>> U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
>> Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
>> bili naoruzani. -- Mladen Gogala

> IMHO, you are barking up the wrong tree.
> EH is bad not because it's slow or costly, but because of its messy semantics.

What's messy with the semantics?

[Juha Nieminen]

In comp.lang.c++ Mel <m...@zzzzz.com> wrote:
>> Your information is out of date for a couple of decades. The
> current C++
>> compilers have implemented zero cost exceptions (in the no-throw
> path)
>> already long time ago.
>
> That's simply impossible.

That's like saying that a longjmp() being zero-overhead (with respect to
all the code that's executed when no jump is done) is "impossible".

You can set up a long jump, and no other code that you call gets any
slower or suffers from any overhead. It's only when something triggers that
long jump that something special happens.

Exceptions are not identical to that, but it's not that far off. But the end
result is that if no exception is thrown, no code suffers from any overhead.

[Ian Collins]

On 30/08/2019 20:43, Mel wrote:
> On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero
> <Bonita....@gmail.com> wrote:
>
>> The non-throw-case takes almost no or no performance.
>
> That's no true. You have to install handlers evrry time or prepare
> tbla for each function at program start...

Have you actually measured the difference? I have on several occasions
and yes, the no-throw path with exceptions is faster (even if only
slightly) than testing error returns. It is also foolproof..

--
Ian.

[Bonita Montero]

> It is also foolproof..

It is not absolutely foolproof because there might be exceptions that
will be uncaught. That's the reason I like checked exceptions in Java
so much.
But it is by magnitudes more convenient as to return and evaluate
return-codes.

[Anton Shepelev]

Bonita Montero to already5chosen:

> > EH is bad not because it's slow or costly, but because
> > of its messy semantics.
>
> What's messy with the semantics?

By looking at any piece of contiguous code you can't say
where its execution is going to be suddenly interrupted and
jump to another unobvous place. Code with exceptions is not
local because its execution depends on any try blocks
anywhere up the call stack. Code with exceptions is not
transparent, because it hides the error-handling part of the
algorithm, and incomplete information is akin to a lie.

--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

[Ian Collins]

On 31/08/2019 12:05, Anton Shepelev wrote:
> Bonita Montero to already5chosen:
>
>>> EH is bad not because it's slow or costly, but because
>>> of its messy semantics.
>>
>> What's messy with the semantics?
>
> By looking at any piece of contiguous code you can't say
> where its execution is going to be suddenly interrupted and
> jump to another unobvous place. Code with exceptions is not
> local because its execution depends on any try blocks
> anywhere up the call stack. Code with exceptions is not
> transparent, because it hides the error-handling part of the
> algorithm, and incomplete information is akin to a lie.

You could equally say that code with exceptions emphasises the error
handling be concentrating it in one place. Often a process with many
steps either works or fails, so handling the errors in one place makes
sense. Throwing exceptions also makes the error handling easier to
spot, you just look for the throws.

--
Ian.

[Bonita Montero]

>> What's messy with the semantics?

> By looking at any piece of contiguous code you can't say
> where its execution is going to be suddenly interrupted
> and jump to another unobvous place.

The code that throws an exception doesn't need to know where
the exception is caught.

[Öö Tiib]

On Friday, 30 August 2019 09:13:33 UTC+3, Mel wrote:
> On Thu, 29 Aug 2019 14:53:05 +0200, Bonita Montero
> <Bonita....@gmail.com> wrote:
> > Rust is nice, but Rust has no exceptions. I wouldn't like to
> evaluate
> > this combined error- and return-values after each function-call that
> > might fail.
>
> That's Rust advantage. Returnig discriminated union is right way for
> handling errors. Rust has syntactic sugar in that. Latest proposal
> for c++ exceptions leans toeard that solution.

Perhaps different people think of error handling differently.
I learned programming using BASIC interpreter in eighties and
there was ERROR statement for generating errors and ON ERROR GOTO
statement for trapping those to handler. Logic was to keep the
already messy algorithms expressed in BASIC cleaner by handling
errors in separate place. C and C++ with no error handling in
language and most errors just left to be undefined behavior
felt seriously inferior because of that. When Microsoft added
SEH exceptions to both C and C++ in nineties then it felt good
extension.

[Mr Flibble]

On 30/08/2019 12:08, David Brown wrote:
>
> I'm happy with a claim "Table driven exceptions are generally faster,
> when there are no errors, than other handling techniques for typical
> code on PC's". What I am /not/ happy with is "Exception handling is
> faster than other error return techniques".

That statement just shows us that you are clueless on the subject of
exceptions. Firstly exceptions are not just for errors. Secondly manually
propagating an error code up the stack manually translating to make it
suitable for one abstraction layer to the next is both an antiquated way
of doing things and a fucktarded way of doing things. If you like error
codes so much then stick to fucking C.

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[Paavo Helde]

On 31.08.2019 3:05, Anton Shepelev wrote:
> Bonita Montero to already5chosen:
>
>>> EH is bad not because it's slow or costly, but because
>>> of its messy semantics.
>>
>> What's messy with the semantics?
>
> By looking at any piece of contiguous code you can't say
> where its execution is going to be suddenly interrupted and
> jump to another unobvous place.

In C++ this is a no-brainer, you don't need to know or care where the
code execution can be interrupted. This is because every allocated
resource is protected and released by RAII automatically, regardless of
if there is an exception or not. This means using things like
std::make_unique() instead of new, etc.

IOW, in C++ you just code with the assumption that about every line can
throw an exception, if not now, then in the future. There are only some
special places where one needs to care about thrown exceptions, namely
noexcept functions like destructors, swappers and like. With proper RAII
very few classes need such functions.

> Code with exceptions is not
> local because its execution depends on any try blocks
> anywhere up the call stack. Code with exceptions is not
> transparent, because it hides the error-handling part of the
> algorithm, and incomplete information is akin to a lie.

This might sound nice in theory, but in reality the error handling part
cannot be part of the actual code because more often than not this code
has no idea how to react to the error. Let's say an input data file
cannot be opened by some number-crunching library. How should it handle
this error? Should it abort the whole program, or should it pop up a
dialog asking the user to correct the problem and retry? What if it runs
in a web server where there is no user to click on the dialog?

The error handling logic is altogether at a different level than the
low-level code which tries to open the file, and the low-level code
cannot and should not contain any "handling" of such errors, it should
just report them to the caller. Exceptions are the most convenient way
for doing this, in particular they can easily encapsulate much more
detailed information about the problem than just some cryptic error code.

[Bonita Montero]

> Exceptions are the most convenient way
> for doing this, in particular they can easily encapsulate much more
> detailed information about the problem than just some cryptic error
> code.

What I don't like with C++ is that exceptions aren't usually
concatenated as like in Java, which is good for debugginig-purposes.
In Java you throw a highly specific checked exception-type at the
point where the error occurs and the exception might get caught up
the call-stack and concatenated into an more general exceptiont
-type. I.e. a JDBC-driver might throw a I/O-error when the socket
is dropped by the OS, there is a specific socket exception-class
thrown and further up the call -levels this is wrapped in a more
general JDBC-error-class; this is done in this way: "throw new
OuterExceptionClass( inner );".
In C++ this isn't directly possible because new might throw bad
_alloc. The only way I can imagine to do this is to have thread
-local / static exception-objects which are thrown when appropriate.

[Manfred]

On 8/30/19 1:47 PM, Bonita Montero wrote:
[...]

>
>>> Almost right, but it doesn't depend on the performance of the CPU.
>>> Even on small CPUs the performance of processing a resurce- or I/O
>>> -collapse doesn't count.
>
>> Incorrect.
>
> No, correct.

No, incorrect.

>
>> Performance under the worst case is often a critical feature of high
>> reliability systems.
>
> When you have a resource or I/O-collapse, you don't have reliability
> anyway.
>

Correctness of behavior (which includes controlled performance) under
stress conditions (including resource exhaustion) is a critical
requirement of high reliability systems - that's what they are made for.
It appears you don't have much experience with such systems.

>
>>> That's true, but then you wouldn't use C++.
>
>> Nonsense.  There are many good reasons to use C++, and many features
>> that can be used, without leading to any inefficiency or bloat.
>
> Almost the whole standard-libary uses an allocaor which might
> throw bad_alloc; not to use the standard-library isn't really C++.

Incorrect as well.

As a first one can replace the allocator in all standard library
facilities, and more generally one can use many features of C++ (e.g.
templates, generic programming, metaprogramming, constexpr (aka
compile-time processing), ...) with no need for any runtime-hungry
technology.

[Bonita Montero]

>> When you have a resource or I/O-collapse, you don't have reliability
>> anyway.

> Correctness of behavior (which includes controlled performance) under
> stress conditions (including resource exhaustion) is a critical
> requirement of high reliability systems - that's what they are made for.
> It appears you don't have much experience with such systems.

The correctnes is also guaranteed with exceptions. But they might have
higher runtime-overhead when being thrown. But this absolutely doesn't
matter because the resouce- or I/O-collapse case isn't performance
-relevant. So I'm not incorrect.
And consider what you would do with return-codes: you would evaluate
them at every call-level and convert them into a special return-code
appropriate for the function-level. This is also likely to be very
inperformant.

>> Almost the whole standard-libary uses an allocaor which might
>> throw bad_alloc; not to use the standard-library isn't really C++.

> Incorrect as well.

N, true.

> As a first one can replace the allocator in all standard library

> facilities, ...

Doing this without throwing an exception like bad_alloc from an allo-
cator doesn't work. This is because there is no way to signal a memory
-collapse differently than through throwing an exception on the usual
container-operations. Dropping the facilities that might throw excep-
tions isn't really C++

[David Brown]

On 30/08/2019 13:47, Bonita Montero wrote:
>> Usually it is faster when exceptions are not thrown, but a lot slower
>> when they /are/ thrown.  But "usually" is not "always".  And for some
>> situations, it is the worst case performance - the speed when there is a
>> problem - that is critical.
>
> The case when an exception is thrown isn't performance-relevant
> as this occurs when there's an resource- or I/O-collapse.

As seems to be the case depressingly often, you are over-generalising
from certain types of software.

For some software, exceptions are ruled out as a technique because they
take too long, and in particular, their timing is very hard to predict.
For real-time programming, it doesn't matter how fast the usual
situation runs. It matters that even in the worst case, you know how
long the code will take. It is a world outside your experience and
understanding, apparently, but it is a vital part of the modern world.

>
>> Fair enough - though convenience is also a subjective matter.
>
> That's rather not subjective here because evaluating return-codes on
> every call-level is a lot of work.
>

Again, you don't see the big picture and think that your ideas cover
everything.

Dealing with return codes on every call level is only a lot of work if
you have lots of call levels between identifying a problem and dealing
with it. And using exceptions is a /huge/ amount of work for some kinds
of analysis of code and possible code flows. By being explicit and
clearly limited, return code error handling is far simpler to examine
and understand, and it is far easier to test functions fully when you
don't have to take into account the possibility of an unknown number of
unknown exceptions passing through.

As I have said, different ways of handling errors have their pros and
cons, and there is no one way that is best for all cases.

>
>>> 3. When you come to the excepion-handling mechanism like in Java
>>>     with checked and unchecked exceptions, you get the best solution.
>>>     But for compatibility-reasons with C this isn't possible in C++.
>
>> Checked exceptions - where the type of exceptions that a function may
>> throw or pass on is part of the signature - are safer, clearer and more
>> efficient.  (Compilers can use tables or code branches, whichever is
>> most convenient).  But they involve more explicit information, which
>> some people like and others dislike.  And they can't pass through
>> functions compiled without knowledge of the exceptions - such as C
>> functions compiled by a C compiler.
>
> Can you read what I told above?

I elaborated on what you wrote.

>
>>> Almost right, but it doesn't depend on the performance of the CPU.
>>> Even on small CPUs the performance of processing a resurce- or I/O
>>> -collapse doesn't count.
>
>> Incorrect.
>
> No, correct.

I'm sorry, but you are making bald statements with apparently no
knowledge or experience in the area.

>
>> Performance under the worst case is often a critical feature of high
>> reliability systems.
>

> When you have a resource or I/O-collapse, you don't have reliability
> anyway.
>

You do understand that people use exceptions for a variety of reasons,
don't you? You do realise that people sometimes write safe and reliable
software that is designed to deal with problems in a reasonable fashion?
If "throw an exception" simply means "there's been a disaster - give
up on reliability, accept that the world has ended and it doesn't matter
how slowly we act as the program is falling apart" then why have an
exception system in the first place? Just call "abort()" and be done
with it.

>
>>> That's true, but then you wouldn't use C++.
>
>> Nonsense.  There are many good reasons to use C++, and many features
>> that can be used, without leading to any inefficiency or bloat.
>

> Almost the whole standard-libary uses an allocaor which might
> throw bad_alloc; not to use the standard-library isn't really C++.

That's bollocks on so many levels, it's not worth trying to explain them
to you.

[David Brown]

On 31/08/2019 14:20, Mr Flibble wrote:
> On 30/08/2019 12:08, David Brown wrote:
>>
>> I'm happy with a claim "Table driven exceptions are generally faster,
>> when there are no errors, than other handling techniques for typical
>> code on PC's".  What I am /not/ happy with is "Exception handling is
>> faster than other error return techniques".
>
> That statement just shows us that you are clueless on the subject of
> exceptions.

You are jumping in to a discussion without following the details.

> Firstly exceptions are not just for errors.

I realise that. The discussion was about error handling techniques,
including alternatives to exceptions for handling errors.

And of course, there is no single definition of "error" anyway - it
means different things in different contexts.

> Secondly
> manually propagating an error code up the stack manually translating to
> make it suitable for one abstraction layer to the next is both an
> antiquated way of doing things and a fucktarded way of doing things.

It is an excellent way of handling things in some cases. If you had
been paying attention and read my posts before replying, you'd have seen
I have argued that a variety of techniques can be useful in different
cases - exceptions are often a good choice, but they are most certainly
not always the right choice.

> If
> you like error codes so much then stick to fucking C.
>

Don't be such a child.

[David Brown]

On 31/08/2019 16:17, Paavo Helde wrote:
> On 31.08.2019 3:05, Anton Shepelev wrote:
>> Bonita Montero to already5chosen:
>>
>>>> EH is bad not because it's slow or costly, but because
>>>> of its messy semantics.
>>>
>>> What's messy with the semantics?
>>
>> By looking at any piece of contiguous code you can't say
>> where its execution is going to be suddenly interrupted and
>> jump to another unobvous place.

C++ exceptions have been described as "undocumented gotos". The
description is, I think, quite fair. That does not necessarily make
them a bad thing - they can often be a good choice in coding.

Different types of coding need different balances, and programming is
always a matter of picking appropriate balances. Sometimes you want
automatic and implicit, sometimes you want manual and explicit. C++
offers you much more flexibility than most languages in finding balances
that work well for the code you are writing - you learn the options and
their pros and cons, and make your choices.

>
> In C++ this is a no-brainer, you don't need to know or care where the
> code execution can be interrupted. This is because every allocated
> resource is protected and released by RAII automatically, regardless of
> if there is an exception or not. This means using things like
> std::make_unique() instead of new, etc.

RAII to protect resources is not remotely dependent on exceptions :

std::optional<int> foo(int x) {
auto a = std::make_unique<int>(x);
auto b = dosomething(a);
if (!b) return std::nullopt;
dosomethingelse(a, b);
return calc(a);
}

You don't need exceptions to avoid leaks and tidy up resources - RAII
gives you that regardless. Returning with error codes (or
std::optional, or new suggestions like "expected", or whatever) is just
as good from that viewpoint.

>
> IOW, in C++ you just code with the assumption that about every line can
> throw an exception, if not now, then in the future. There are only some
> special places where one needs to care about thrown exceptions, namely
> noexcept functions like destructors, swappers and like. With proper RAII
> very few classes need such functions.
>
> > Code with exceptions is not
>> local because its execution depends on any try blocks
>> anywhere up the call stack.  Code with exceptions is not
>> transparent, because it hides the error-handling part of the
>> algorithm, and incomplete information is akin to a lie.
>
> This might sound nice in theory, but in reality the error handling part
> cannot be part of the actual code because more often than not this code
> has no idea how to react to the error.

And therein lies the problem, when you are concerned with being able to
be sure your code is correct (both by design, and by testing).

> Let's say an input data file
> cannot be opened by some number-crunching library. How should it handle
> this error? Should it abort the whole program, or should it pop up a
> dialog asking the user to correct the problem and retry? What if it runs
> in a web server where there is no user to click on the dialog?

Separate the concerns. Don't make a function (or class, or unit, or
whatever code size is appropriate) that reads data from a file and
crunches it. Make a function that reads data from the file. Make
another function that crunches data.

Or make a function that will attempt to read the data from the file and
crunch it, returning the correct result or some sort of error indicator
when a problem is found. That error indicator could be an error code, a
std::optional nullopt, a tuple field in the result - or a thrown exception.

But now, instead of having a function that lives in a happy, optimistic,
carefree and unrealistic world, with no sense of responsibility and an
"I don't care, it's someone else's problem" attitude, you've got a
function that is clear and complete. If there is a problem, it will
tell you - and it will do so in a way that you know about and
understand, and that you can test. Your function no longer has errors -
it has a wider scope of correct, specified, tested and documented,
behaviour. (And yes, you can use exceptions for this just as well as
other error techniques.)

[Bonita Montero]

> For some software, exceptions are ruled out as a technique because they
> take too long, and in particular, their timing is very hard to predict.

Another time: the performance of resource- or I/O-collapse-handling
is never relevant.

>> That's rather not subjective here because evaluating return-codes on
>> every call-level is a lot of work.

> Again, you don't see the big picture and think that your ideas cover
> everything.

I see "the big picture" - you are not.

> Dealing with return codes on every call level is only a lot of work if
> you have lots of call levels between identifying a problem and dealing
> with it.  And using exceptions is a /huge/ amount of work for some kinds
> of analysis of code and possible code flows.

Wrong; you catch them in a central point and that's all.

>> When you have a resource or I/O-collapse, you don't have reliability
>> anyway.

> You do understand that people use exceptions for a variety of reasons,
> don't you?

They are used for resource- or I/O-collapse - and nothing more.

> f "throw an exception" simply means "there's been a disaster - give
> up on reliability, accept that the world has ended and it doesn't matter
> how slowly we act as the program is falling apart" then why have an
> exception system in the first place?  Just call "abort()" and be done
> with it.

You don't have any reliability any more at this point because the
operation simply failed. The timing isn't relevant any more a this
point.

[Öö Tiib]

On Sunday, 1 September 2019 06:16:45 UTC+3, Bonita Montero wrote:

> On Sunday, 1 September 2019 00:40:08 UTC+3, David Brown wrote:
> > For some software, exceptions are ruled out as a technique because they
> > take too long, and in particular, their timing is very hard to predict.
>
> Another time: the performance of resource- or I/O-collapse-handling
> is never relevant.

Where it is written that exceptions are only for handling resource
or I/O collapse?
Exceptions are typically thrown in situation when a function
(such as operator or constructor) can't fulfill its post-conditions.
Running out of resources or failures of I/O are just easy examples
why it may happen.

> >> That's rather not subjective here because evaluating return-codes on
> >> every call-level is a lot of work.
>
> > Again, you don't see the big picture and think that your ideas cover
> > everything.
>
> I see "the big picture" - you are not.

Yet the current exceptions can’t be used for some hard-real time
projects exactly because of bad performance on failure case.
See http://stroustrup.com/JSF-AV-rules.pdf
Basically they have to extend their post-conditions of all functions
that may fail with failure state and to check it. And you don't seem
to understand why it is so.

[Bonita Montero]

> Running out of resources or failures of I/O are just easy examples
> why it may happen.

Tell me more where exceptions might be used!

[Bonita Montero]

>> Running out of resources or failures of I/O
>> are just easy examples why it may happen.

> Tell me more where exceptions might be used!

Or better: mention a class-library that uses exceptions
for something different than what I told!

[Öö Tiib]

Huh? C++ standard library and <https://www.boost.org/> contain piles
of throws for numerous other reasons. Rather elementary things
like Boost.Lexical_Cast may fail and throw.

[Ian Collins]

Even more basic, std::vector::at().

--
Ian.

[Bonita Montero]

>> Huh? C++ standard library and <https://www.boost.org/> contain
>> piles of throws for numerous other reasons. Rather elementary
>> things like Boost.Lexical_Cast may fail and throw.

> Even more basic, std::vector::at().

OK, you're right. But the first exception isn't thrown in a per
-formance-relevant case. .at is, but this might make it useless
in many cases as eceptions are slow.
I just measured the performance of trowing an int and catching
an int & with VC++ and it is about 3 million clock-cycles:

// main translation-unit
#include <windows.h>
#include <iostream>
#include <intrin.h>

void Thrower();

using namespace std;

int main()
{
// to get always the same TSC
SetThreadAffinityMask( GetCurrentThread(), 1 );

typedef long long LL;
unsigned const REP = 1'000;
LL start, end;

start = (LL)__rdtsc();
for( unsigned i = REP; i; --i )
try
{
Thrower();
}
catch( int & )
{
}
end = (LL)__rdtsc();
cout << (double)(end - start) / REP << endl;
}

// throwing translation-unit
void Thrower()
{
throw int( 123 );
}

Maybe anyone could adapt this for other compilrs / platforms;
I'm curious about the results. Compile it without interprocedural
optimizations to prevent the compiler from optimizing away the
whole throw-try-catch-issue.

[Paavo Helde]

On 1.09.2019 1:06, David Brown wrote:
> On 31/08/2019 16:17, Paavo Helde wrote:
>> On 31.08.2019 3:05, Anton Shepelev wrote:
>
> RAII to protect resources is not remotely dependent on exceptions :

Sure, but exceptions are dependent on RAII. Without RAII it is not
really feasible to use exceptions, as demonstrated by ugly, tedious and
error-prone 'finally' clauses in C# and elsewhere.

>> > Code with exceptions is not
>>> local because its execution depends on any try blocks
>>> anywhere up the call stack. Code with exceptions is not
>>> transparent, because it hides the error-handling part of the
>>> algorithm, and incomplete information is akin to a lie.
>>
>> This might sound nice in theory, but in reality the error handling
>> part cannot be part of the actual code because more often than not
>> this code has no idea how to react to the error.
>
> And therein lies the problem, when you are concerned with being able to
> be sure your code is correct (both by design, and by testing).
>
>> Let's say an input data file cannot be opened by some number-crunching
>> library. How should it handle this error? Should it abort the whole
>> program, or should it pop up a dialog asking the user to correct the
>> problem and retry? What if it runs in a web server where there is no
>> user to click on the dialog?
>
> Separate the concerns. Don't make a function (or class, or unit, or
> whatever code size is appropriate) that reads data from a file and
> crunches it. Make a function that reads data from the file. Make
> another function that crunches data.

There is no difference, the function reading the data still has no clue
how to "handle" an error.

> Or make a function that will attempt to read the data from the file and
> crunch it, returning the correct result or some sort of error indicator
> when a problem is found. That error indicator could be an error code, a
> std::optional nullopt, a tuple field in the result - or a thrown exception.

Right, the function cannot handle the error by itself and reports it
back to the caller. Ergo, the error handling code resides somewhere else
than in this low-level function, ruining the dubious "transparency"
ideal advocated by GP.

The distance between error detection and handling is different in
different kind of software. It might be that the error is handled 1 - 2
call stack frames up, making the error code approach pretty
straightforward. In the code I usually work with this distance is
typically 10 - 20 call stack frames, making the exceptions approach much
more convenient.

[David Brown]

On 01/09/2019 05:16, Bonita Montero wrote:
>> For some software, exceptions are ruled out as a technique because
>> they take too long, and in particular, their timing is very hard to
>> predict.
>
> Another time: the performance of resource- or I/O-collapse-handling
> is never relevant.
>

All I can say is that I am glad I don't have to rely on your software.
It's one thing to be ignorant - but your blind, stubborn, wilful and
insistent ignorance is fortunately exceptional.

[David Brown]

On 01/09/2019 14:49, Paavo Helde wrote:
> On 1.09.2019 1:06, David Brown wrote:
>> On 31/08/2019 16:17, Paavo Helde wrote:
>>> On 31.08.2019 3:05, Anton Shepelev wrote:
>>
>> RAII to protect resources is not remotely dependent on exceptions :
>
> Sure, but exceptions are dependent on RAII. Without RAII it is not
> really feasible to use exceptions, as demonstrated by ugly, tedious and
> error-prone 'finally' clauses in C# and elsewhere.
>

Agreed. You need RAII - or, more specifically, deterministic
destructors - for exceptions to work well. My point is merely that you
get the RAII advantages no matter how you handle errors or unusual
situations, whether it be C++ exceptions, future "zero overhead" or
"checked" exceptions, error return codes, or anything else.

>>>  > Code with exceptions is not
>>>> local because its execution depends on any try blocks
>>>> anywhere up the call stack.  Code with exceptions is not
>>>> transparent, because it hides the error-handling part of the
>>>> algorithm, and incomplete information is akin to a lie.
>>>
>>> This might sound nice in theory, but in reality the error handling
>>> part cannot be part of the actual code because more often than not
>>> this code has no idea how to react to the error.
>>
>> And therein lies the problem, when you are concerned with being able to
>> be sure your code is correct (both by design, and by testing).
>>
>>> Let's say an input data file cannot be opened by some number-crunching
>>> library. How should it handle this error? Should it abort the whole
>>> program, or should it pop up a dialog asking the user to correct the
>>> problem and retry? What if it runs in a web server where there is no
>>> user to click on the dialog?
>>
>> Separate the concerns.  Don't make a function (or class, or unit, or
>> whatever code size is appropriate) that reads data from a file and
>> crunches it.  Make a function that reads data from the file.  Make
>> another function that crunches data.
>
> There is no difference, the function reading the data still has no clue
> how to "handle" an error.

That can be true - but a key difference is that the reading function
knows there can be errors. It might not handle those errors, but it
does not ignore the possibility of their existence.

>
>> Or make a function that will attempt to read the data from the file and
>> crunch it, returning the correct result or some sort of error indicator
>> when a problem is found.  That error indicator could be an error code, a
>> std::optional nullopt, a tuple field in the result - or a thrown
>> exception.
>
> Right, the function cannot handle the error by itself and reports it
> back to the caller. Ergo, the error handling code resides somewhere else
> than in this low-level function, ruining the dubious "transparency"
> ideal advocated by GP.
>
> The distance between error detection and handling is different in
> different kind of software. It might be that the error is handled 1 - 2
> call stack frames up, making the error code approach pretty
> straightforward. In the code I usually work with this distance is
> typically 10 - 20 call stack frames, making the exceptions approach much
> more convenient.
>

Sure, if exceptions are right for your code, use exceptions. I am not
suggesting that exceptions are bad - merely that they are not always the
best choice.

[Bonita Montero]

> All I can say is that I am glad I don't have to rely on your software.
> It's one thing to be ignorant - but your blind, stubborn, wilful and
> insistent ignorance is fortunately exceptional.

You're a mega-idiot as you don't understand that error-handling isn't
performance-crucial.

[Richard Damon]

If the result of not handling the error in time is someone gets killed,
maybe it is.

'Error' Handling often can be a critical part of the system (and
sometimes it isn't).

The issue is that 'Generic' answers aren't always right, sometimes
certain things are important, and sometimes they are not.

In many cases, the cost of the exception path isn't that important, but
sometimes real WORSE case performance is, sometimes the error path may
have relaxed requirements, but sometimes it still has definite
requirements.

Exceptions can't be true Zero overhead, they may be able to push the
overhead into things that aren't important most of the time, but might
be important in some cases. The shifting of exception cost to static
data/code space and away from execution time is good in many cases, but
it does raise the cost of the exception path, sometimes significantly
(and perhaps too high of a cost). Error Return Values sometimes have the
advantage that the cost is up front and more directly controllable, the
cost of exceptions is very much fixed by the implementation, and not as
controllable. If your usage matches the cases that the implementation
optimized for, it can be good, if not, it may not be so good.

[David Brown]

On 01/09/2019 21:23, Richard Damon wrote:
> On 9/1/19 12:22 PM, Bonita Montero wrote:
>>> All I can say is that I am glad I don't have to rely on your software.
>>> It's one thing to be ignorant - but your blind, stubborn, wilful and
>>> insistent ignorance is fortunately exceptional.
>>
>> You're a mega-idiot as you don't understand that error-handling isn't
>> performance-crucial.
>>
>
> If the result of not handling the error in time is someone gets killed,
> maybe it is.

And that is the point. (Though it is much broader than live-critical code.)

Bonita seems to think the world runs on programs on desktops, where it
is fine to have error messages popping up saying "There was an error
saving the file to disk. Press OK to continue". For some programs,
that kind of error handling is fine. But for some programs, it is /not/
fine at all, and /timely/ handling of errors is critical for your car to
work, your telephone to work, your insulin pump to work, your cable TV
service to work.

>
> 'Error' Handling often can be a critical part of the system (and
> sometimes it isn't).
>

Yes.

> The issue is that 'Generic' answers aren't always right, sometimes
> certain things are important, and sometimes they are not.
>

I'd go further, and say that generic answers are wrong so often that
they are simply "wrong".

> In many cases, the cost of the exception path isn't that important, but
> sometimes real WORSE case performance is, sometimes the error path may
> have relaxed requirements, but sometimes it still has definite
> requirements.
>

Exactly.

A key concept here is "real time system". That is used to mean things
happen within particular times - known, pre-determined times. Deadlines
are hard - you don't get to miss them. It doesn't matter if a system is
fast or slow, it matters that it is predictable and guaranteed. It
doesn't matter if returning std::optional takes ten times as long as
using exceptions in non-error situations, if it means you avoid the
possibility of suddenly taking a thousand times as long, or the even
worse possibility of not knowing how long the exception handling will take.

Requirements about predictable and limited timing, even in the face of
some kinds of problems or errors, are common in many types of coding.
It doesn't have to be critical to live and health - it can be critical
to business and economic effects too. And it can be critical to
software being acceptable to users - games players are not keen on
unexpected pauses in the middle of battles.

> Exceptions can't be true Zero overhead, they may be able to push the
> overhead into things that aren't important most of the time, but might
> be important in some cases. The shifting of exception cost to static
> data/code space and away from execution time is good in many cases, but
> it does raise the cost of the exception path, sometimes significantly
> (and perhaps too high of a cost). Error Return Values sometimes have the
> advantage that the cost is up front and more directly controllable, the
> cost of exceptions is very much fixed by the implementation, and not as
> controllable. If your usage matches the cases that the implementation
> optimized for, it can be good, if not, it may not be so good.
>

Absolutely.

[Bonita Montero]

> If the result of not handling the error in time is someone gets killed,
> maybe it is.

We're not discussing about error handling or not;
wer're discussing the performance-impacts.

> In many cases, the cost of the exception path isn't that important, but
> sometimes real WORSE case performance is, sometimes the error path may
> have relaxed requirements, but sometimes it still has definite
> requirements.

You don't have any clue what you're talking about.
You simply fantasizing to emphasize your authority.

[Bonita Montero]

Sorry, I had a background task that was encoding a video through
x265. I thought that it is simply sufficient to put it on idle
-priority. But the issue I hadn't in mind was that this task is
stealing "cycles" on the the other thread of a core.
Without any competing cycles on that core the time to throw and
catch an exception is only about 8.600 cycles on my Ryzen 7 1800X.
But I'm still curious about the performance of other implementa-
tions.

[Richard Damon]

On 9/2/19 12:47 AM, Bonita Montero wrote:
>> If the result of not handling the error in time is someone gets killed,
>> maybe it is.
>
> We're not discussing about error handling or not;
> wer're discussing the performance-impacts.

Yes, we are talking about the performance impact of error handling.

>
>> In many cases, the cost of the exception path isn't that important, but
>> sometimes real WORSE case performance is, sometimes the error path may
>> have relaxed requirements, but sometimes it still has definite
>> requirements.
>
> You don't have any clue what you're talking about.
> You simply  fantasizing to emphasize your authority.
>

As an example, lets take sending data to the flight recorder in an
airplane. Errors may well occur during this operation (perhaps one log
fills so you need to switch to another). There may well be a piece of
this in the critical control loops. If an error delays the loop, then
perhaps some critical function fails, perhaps causing a loss of control
of the system.

Likely the critical control loop isn't directly communicating with the
flight recorder, but with an intermediary operation to provide some
buffering, but if the intermediary operation gets delayed too much in
sending the data to the flight recorder, it might not service the
control loop fast enough, causing the problems.

I don't work on airplanes (but I do work with real time systems), so
this exact case may not apply, but is a fairly graphic one which shows
that in a real time system, even errors need to be handled within time
limits. People who are used to 'PC' or 'Server' Class machines often
don't understand the real time world, On the PC 0.1 second response is
often good enough, maybe with a real-time interactive game it goes down
to 0.01 seconds, and not meeting that time mark is just a minor
'performance' issue. In a true real time system the time period is often
much shorter, and the cost of not meeting the time requirements are
often much more significant, something stopped working.

[Bonita Montero]

> As an example, lets take sending data to the flight recorder in an
> airplane. Errors may well occur during this operation (perhaps one log
> fills so you need to switch to another). There may well be a piece of
> this in the critical control loops. If an error delays the loop, then
> perhaps some critical function fails, perhaps causing a loss of control
> of the system.

Such systems have their critical resources allocated at startup that
those situations don't occur.

[Manfred]

You really can't get it, can you?

[Richard Damon]

Out of Resources is not the only type of error that typcially generates
an exception. Some would have critical I/O errors be reported back as
exceptions (Remember the original discussion was Exceptions vs testing
return values). If one write in a billion might generate the error
condition, by many people that would be considered 'exceptional' and
properly done with an exception.

On a PC, if once every billion operations we got a slight additional
delay to the user, that would be normally acceptable. If that one in a
billion causes your airplane engine to stall in mid air, it wouldn't be.

[Bonita Montero]

> Out of Resources is not the only type of error that typcially generates
> an exception. Some would have critical I/O errors be reported back as

> exceptions ..

Have you considered the part of such an I/O-operation that might fail
is the kernel-call that has a higher processing-overhead than the error
-handling itself?

[Richard Damon]

Kernel, what kernel. From my experience, most of the truly real time
systems have nothing remotely like a *nix or Windows kernel anywhere in
them. They are running on machines much smaller than your typical X86
processor which is focused on a particular job. I/O operations are quick
an efficient, and there isn't the heavy security isolation of a large
monolithic operating system.

People whose world is all monolithic OS machines, with heavy isolation
between processes and high costs of context switches to do many things
may have trouble understanding the very different world of the smallish
processor running much closer to bare metal to get the job done quickly,
efficiently, and ON TIME. Different problems need different sorts of
solutions which have different types of environments that they run under.

[Bonita Montero]

>> Have you considered the part of such an I/O-operation that might fail
>> is the kernel-call that has a higher processing-overhead than the error
>> -handling itself?

> Kernel, what kernel. From my experience, most of the truly real time
> systems have nothing remotely like a *nix or Windows kernel anywhere
> in them.

He was talking about flight-computers. And almost every flight-computer
uses VxWorks.
And you don't have any "experience" on that.

[David Brown]

No, they don't.

VxWorks is certainly a possible option for flight computers, but it is
by no means dominant. Indeed, /no/ OS is dominant for such uses - you
use redundant systems with different software and hardware.

And he was talking about flight recorders (black boxes), not flight
computers.

> And you don't have any "experience" on that.

Nor do you. The difference is, others understand their experiences and
limitations, understand the differences in various fields of
programming, and try to expand their knowledge beyond their fields (even
when they never actually work on those systems). They don't extrapolate
wildly from one small area of software, and they don't make wild claims
with no evidence or reference.

[Bonita Montero]

> Nor do you.  The difference is, others understand their experiences and
> limitations, understand the differences in various fields of
> programming, and try to expand their knowledge beyond their fields (even
> when they never actually work on those systems).  They don't extrapolate
> wildly from one small area of software, and they don't make wild claims
> with no evidence or reference.

No one here has experience with systems where they think exception
-handling should be inappropriate for performance-reasons; that's
all pure phantasy.

[David Brown]

Sorry, you are wrong again. I have worked on several systems where
exception handling would have been ruled out for performance reasons
(had the software been written in C++, rather than C). They would have
been ruled out of those projects for several reasons, in fact -
exceptions are often not suitable where you have tight safety
requirements. (You'll be shocked to hear that dynamic memory is also
banned in such software.)

For most of my C++ projects, exceptions are not used at all. It would
simply be unacceptable for there to be errors where throwing an
exception could be at all useful - therefore any exception support is
pure overhead, and they are disabled at the tool level.

[Bonita Montero]

> Sorry, you are wrong again. I have worked on several systems where
> exception handling would have been ruled out for performance reasons
> (had the software been written in C++, rather than C).

I don't believe you.

[David Brown]

I don't care.

[Richard Damon]

The fact that you haven't encountered significantly tight real-time
requirements doesn't mean they don't exist. I can say from experience
that there ARE cases with rules like this, and they have good grounds to
exist.

Exceptions work in many environments, but not all. Error code returns
work in many environments too. Which methods are usable, and which
methods are good to use, and which method is best, are VERY subject to
the domain you are working in. To think that one method is best
everywhere is very myopic, and says that one has been in just a small
part of the total space of programming.

[Bonita Montero]

>> I don't believe you.

> The fact that you haven't encountered significantly tight real-time
> requirements doesn't mean they don't exist.

The folks here are Nerds without any experience on that. And if there
are any circumstances that would make error-handling through exception
not feasible because they would be too slow, this would be very rare.
Thus it is not credible that david would have many of such experiences.
He is simply a liar!

[David Brown]

On 03/09/2019 13:17, Bonita Montero wrote:
>>> I don't believe you.
>
>> The fact that you haven't encountered significantly tight real-time
>> requirements doesn't mean they don't exist.
>
> The folks here are Nerds without any experience on that.

And you base that on what evidence?

There are people in this group with experience of all sorts of systems.
There are people who have programmed tiny systems. My own record for
small devices was 1K flash and no ram (programmed in C with gcc). I
have a project coming up with 2K flash and 128 byte ram on the device.

There are people here who have programmed mainframes, supercomputers,
operating systems, hypervisors, games, simulators, emulators,
programming languages. There are people who have programmed
safety-critical systems or high reliability systems (I have personally
worked on a couple of systems where mistakes could cost lives, and
several more where mistakes cost millions. I know I am not alone in
that in this group). And of course there are also those who have "only"
worked on PC software, or who are students, or hobby programmers, or
academics.

> And if there
> are any circumstances that would make error-handling  through exception
> not feasible because they would be too slow, this would be very rare.

No one has denied that it is unusual for the speed of exceptions to be
the reason they can't be used in a project. It is far, far more
important that the speed is unpredictable and you cannot (with any sane
level of effort) be sure of the limits. You don't understand what "real
time" means - please try to learn a little from other people, rather
than parading your ignorance.

> Thus it is not credible that david would have many of such experiences.
> He is simply a liar!
>

Really? You have extrapolated from your own experiences and limited
knowledge, and made wild and unjustified comments about programming
domains well beyond your ken. You combine that with continuous and
apparently wilful misreading of my posts, and that's your conclusion?

So tell me, /why/ do you think I am lying? Do you think I am trying to
appear impressive and gain respect? From whom? The people in this
group whose opinion I respect are not impressed by lies or
exaggerations, and are usually quite good at spotting them. It should
be quite obvious that I have little respect for /you/ at the moment, and
therefore no interest in trying to impress you.

My interest in this discussion has been about sharing experiences and
knowledge, and perhaps giving people something to think about or some
ideas of programming issues beyond those that are familiar to them from
before, and maybe correcting some misconceptions. That is usually what
I look for myself in discussion threads.

It is painfully clear, however, that you are unteachable - your reaction
to being shown something new is denial and insults. This is a shame,
and I hope you will realise it and make an effort to change.

[Bonita Montero]

Liar!

[Bonita Montero]

You try to emphasize your credibility as a developer who ewas involved
in a lot projects like those I told by referring to others her in this
group that have similar special positions. How stupid is that?

[Manfred]

On 9/3/2019 3:42 PM, Bonita Montero wrote:
> Liar!
You really love trolling, don't you?