Asp Forum - Read again about my objection about C++ and C

Ramine

12/30/2015 9:40:00 PM

Hello,

I have just took a look to operator overloading in FreePascal and
Delphi, so look at how powerful it is, here is an example:

===

program OperatorsTest;

{$APPTYPE CONSOLE}

uses
SysUtils;

type
TIntValue = record
private
FValue: Integer;
public
class operator Add(const a, b: TIntValue): TIntValue;
class operator Implicit(const a: Integer): TIntValue;
class operator Implicit(const a: TIntValue): Integer;
property Value: Integer read FValue;
end;

{ TIntValue }

class operator TIntValue.Add(const a, b: TIntValue): TIntValue;
begin
Result.FValue := a.FValue + b.FValue;
end;

class operator TIntValue.Implicit(const a: Integer): TIntValue;
begin
Result.FValue := a;
end;

class operator TIntValue.Implicit(const a: TIntValue): Integer;
begin
Result := a.FValue;
end;

var
Int: TIntValue;

begin
Int := 5;
Int := Int + 10;
WriteLn(IntToStr(Int));

end.
===

You can overload the following operators in both FreePascal and Delphi,
read here:

http://docwiki.embarcadero.com/RADStudio/Seattle/en/Operator_Ov...(Delphi)

In ADA when you define two types like this:

type length is new float;
type weight is new float;

You can not assign type length to type weight, this strong typing
of Ada you can do it easily with object oriented programming in
FreePascal and Delphi and C++.

So what remains about C and C++ is that in C++ and C you can
not at runtime catch the exception of signed int or unsigned int
overflow or underflow , this is a weakness in C++ and C , but
in FreePascal and Delphi you can easily do it by compiling
with the FreePasal compiler option -Co, after that you can catch the
exception named EIntOverflow like this:

try

except
on EIntOverflow do HandleIntOverflow;
end;

And the HandleIntOverflow you can reraise the exception by
returning the name of the function that raised this exception
of the signed or unsigned int overflow or underflow so that to catch the
bugs easily and that's good in realtime safety critical systems, so C++
and C can not do that and this is not suitable for realtime safety
critical system.

Thank you,
Amine Moulay Ramdane.

17 Answers

Richard Heathfield

12/30/2015 6:51:00 PM

On 30/12/15 21:39, Ramine wrote:

[Subject line: Read again about my objection about C++ and C]

Since your knowledge of good C++ programming style is so limited that
you still use 'using namespace std', can you persuade us that your views
on C and C++ are worth anything?

<snip>

> So what remains about C and C++ is that in C++ and C you can
> not at runtime catch the exception of signed int or unsigned int
> overflow or underflow ,

In C and C++, it is not possible to overflow or underflow unsigned
integer types, so there is no way for the exception to be generated.
Even with signed integer types, there is no requirement on architectures
to generate an exception for overflow, and C does not mandate that
implementations carry out software checks, for the excellent reason that
programmers who design their software in such a way that overflow cannot
happen should not be penalised by extra checks every time they add two
numbers together:

int quadratic(int x, int a, int b, int c)
{
return a * x * x + b * x + c;
}

int foo()
{
y = quadratic(3, 2, -3, 4);
z = quadratic(2, 3, -1, 6);
return y + z;
}

For such code, it would be folly to impose a run-time penalty.

> this is a weakness in C++ and C ,

No, it isn't.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Öö Tiib

12/30/2015 7:28:00 PM

Your own argument is stupid.

It is irrelevant for a user of real-time critical incorrect program
what way it burns down: by giving incorrect answers or by throwing
out run-time errors.

Developer can compile with gcc -ftrapv option if he wants integer
overflow to be detected run-time in C or C++. Developers use it
for testing. However giving defective safety-critical software to user
with such run-time checks is still as bad. It just runs slightly slower
but is still as incorrect.

On Wednesday, 30 December 2015 21:03:14 UTC+2, Ramine wrote:
> Hello,
>
>
> You are making your argument stupid..
>
> Because we must have a way in the compiler to discipline the
> programmer to not make a mistake, you are saying that in C and C++
> you have to test for your logic yourself to not overflow
> or underflow, that's not good, because in FreePascal
> and Delphi and Ada, if you want the compiler to discipline
> you to not make an error of logic that makes you overflow
> or underflow a signed or unsigned int, you can compile your program
> in FreePascal with -Co compiler option and after that you can locally
> catch the exception of overflow or underflow and reraise an exception
> to detect the faulty function that caused it, or you can globally
> catch the exception, but you can not do that in C++ and C , so
> this is why in my opinion C and C++ are not suitable for
> realtime safety critical systems.
>
>
>
> Thank you,
> Amine Moulay Ramdane.
>
>
>
> On 12/30/2015 10:50 AM, Richard Heathfield wrote:
> > On 30/12/15 21:39, Ramine wrote:
> >
> > [Subject line: Read again about my objection about C++ and C]
> >
> > Since your knowledge of good C++ programming style is so limited that
> > you still use 'using namespace std', can you persuade us that your views
> > on C and C++ are worth anything?
> >
> > <snip>
> >
> >> So what remains about C and C++ is that in C++ and C you can
> >> not at runtime catch the exception of signed int or unsigned int
> >> overflow or underflow ,
> >
> > In C and C++, it is not possible to overflow or underflow unsigned
> > integer types, so there is no way for the exception to be generated.
> > Even with signed integer types, there is no requirement on architectures
> > to generate an exception for overflow, and C does not mandate that
> > implementations carry out software checks, for the excellent reason that
> > programmers who design their software in such a way that overflow cannot
> > happen should not be penalised by extra checks every time they add two
> > numbers together:
> >
> > int quadratic(int x, int a, int b, int c)
> > {
> > return a * x * x + b * x + c;
> > }
> >
> > int foo()
> > {
> > y = quadratic(3, 2, -3, 4);
> > z = quadratic(2, 3, -1, 6);
> > return y + z;
> > }
> >
> > For such code, it would be folly to impose a run-time penalty.
> >
> >> this is a weakness in C++ and C ,
> >
> > No, it isn't.
> >

kenobi

12/30/2015 7:35:00 PM

W dniu sroda, 30 grudnia 2015 20:03:14 UTC+1 uzytkownik Ramine napisal:
> Hello,
>
>
> You are making your argument stupid..
>
> Because we must have a way in the compiler to discipline the
> programmer to not make a mistake, you are saying that in C and C++
> you have to test for your logic yourself to not overflow
> or underflow, that's not good, because in FreePascal
> and Delphi and Ada, if you want the compiler to discipline
> you to not make an error of logic that makes you overflow
> or underflow a signed or unsigned int, you can compile your program
> in FreePascal with -Co compiler option and after that you can locally
> catch the exception of overflow or underflow and reraise an exception
> to detect the faulty function that caused it, or you can globally
> catch the exception, but you can not do that in C++ and C , so
> this is why in my opinion C and C++ are not suitable for
> realtime safety critical systems.
>
your reasoning is worth a ram..

1) the jump from the lack of integer overflow check in a compiler to reasoning than c and c++ are "not suitable for realtime safety critical systems" is an idiot reasoning (what with a thousand of other properties - they do not matter?)
2) this integer check has not much to c/c++ you may use a small compiler extension to
turn it on - this depends on compiler,
\i wonder if "pascal" language says pascal compiler must have it becouse it is a pascal
3) not to mention other things
4) really great news ramine, youre enlighting a whole world by this precious knowledge
5) stop spamming the groups uninteligent spammer,

Richard Heathfield

12/30/2015 7:42:00 PM

On 30/12/15 22:03, Ramine wrote:
> Hello,

Ah! Welcome to comp.programming!

> You are making your argument stupid..

That's an interesting conversational gambit. Let's see how far it gets you.

> Because we must have a way in the compiler to discipline the
> programmer to not make a mistake,

It is not possible, in the general case, for the compiler to prevent the
programmer from making mistakes, because the compiler doesn't know what
the programmer is supposed to be doing.

> you are saying that in C and C++
> you have to test for your logic yourself to not overflow
> or underflow,

You have to know about the issue, yes, and you have to take sensible
precautions when you're up against limits. The pay-off is performance.
In almost all cases (but not quite all), the precaution is not required,
so why impose that penalty /all/ the time? Why not trust the programmer
to put the checks in when they are required?

> that's not good, because in FreePascal
> and Delphi and Ada, if you want the compiler to discipline
> you to not make an error of logic that makes you overflow
> or underflow a signed or unsigned int, you can compile your program
> in FreePascal with -Co compiler option and after that you can locally
> catch the exception of overflow or underflow and reraise an exception
> to detect the faulty function that caused it, or you can globally
> catch the exception,

To summarise your argument:

1) FreePascal and Delphi and Ada allow you to include runtime overflow
checks.
2) Therefore, not providing runtime overflow checks is bad.

You might want to consider signing up for an Elementary Logic course.

Firstly, as I have already explained, doing such checks automatically
has a runtime overhead that in almost all cases is not required, so it's
mostly just a waste of clocks.

Secondly, and you'll laugh when you hear this, by far the most popular C
and C++ compiler is gcc, which *does* allow you to set up runtime
arithmetic overflow checking if you want to.

> but you can not do that in C++ and C , so

Well, you can if you want, but normally you don't want because it's
normally a complete waste of time.

> this is why in my opinion C and C++ are not suitable for
> realtime safety critical systems.

(a) Your opinion doesn't count for much where the facts are concerned -
C and C++ implementations are perfectly free to provide such checking,
some implementations /do/ provide such checking, and of course they do
so /optionally/;
(b) The reason it's optional is that it's very often not a sensible
option. There's no point in weighing down code with runtime checks that
are never going to fire.

What /is/ sometimes a good idea is to enable such checks during testing,
and design some test cases to expose any overflow issues.

<snip>

One other thing - please learn why top-posting is such a stupid, stupid,
stupid idea. Thank you.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Richard Heathfield

12/30/2015 7:49:00 PM

On 30/12/15 22:41, Ramine wrote:
> On 12/30/2015 11:28 AM, Öö Tiib wrote:
>> Your own argument is stupid.
>>
>> It is irrelevant for a user of real-time critical incorrect program
>> what way it burns down: by giving incorrect answers or by throwing
>> out run-time errors.
>>
>> Developer can compile with gcc -ftrapv option if he wants integer
>
>
> Read here, the -ftrapv is not good:

Translation: you once read something that you interpreted as meaning
that -ftrapv is not good. Well, I once read that Elvis is alive and well
and flipping burgers in an Alabama diner. So what?

<snip>

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Richard Heathfield

12/30/2015 7:51:00 PM

On 30/12/15 22:46, Ramine wrote:

<snip>

> Read here, the -ftrapv is not good:

That is your only comment? You made exactly the same comment (and no
other) in the last article you posted. It was stupid then and it's
stupid now.

Instead of shooting from the hip, try actually *reading* what people
write. You might - and I realise this is a long shot - you might
actually learn something.

<snip>

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Richard Heathfield

12/30/2015 7:52:00 PM

On 30/12/15 22:49, Ramine wrote:
> Hello,
>
> Sorry , here is the right link, the gcc -ftrapv, read here:

Feel free to summarise the article in your own words.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Richard Heathfield

12/30/2015 8:07:00 PM

On 30/12/15 22:49, Ramine wrote:
>
> Hello,
>
> Sorry , here is the right link, the gcc -ftrapv, read here:

You only have to post it once, you know.

The cited book is by Robert Seacord, whom I recall very clearly. I had
long discussions with him on Usenet and in email, about the time he was
writing "The CERT C Coding Standard" (in fact, you will find my name in
the acknowledgements for that work, although not in the work you cited).
I did not find the experience a particularly fruitful one, however,
because - like you - he doesn't really know how to listen. Consequently,
the CERT C Coding Standard is flawed in several important respects. I
currently have no reason to doubt that his book on "Secure Coding in C
and C++" is just as flawed.

In the current case, we see the problem right away:

int x = /* nondeterministic value */

Obviously it doesn't compile, which isn't a great start. But more
importantly, what on earth does he mean by "nondeterministic value"?
Does he mean this?

int x;
x = x + 100 - 1000;

If he does mean that, well, overflow is the least of his problems!

And if he doesn't, what /does/ he mean?

If x has a nondeterministic value, we have no business doing any
arithmetic at all with x until it has been properly initialised!

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Richard Heathfield

12/30/2015 8:07:00 PM

On 30/12/15 22:51, Ramine wrote:
>
> Hello,
>
> Sorry , here is the right link, the gcc -ftrapv is not good, read here:

Same argument as before.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Richard Heathfield

12/30/2015 8:07:00 PM

On 30/12/15 22:52, Ramine wrote:
>
> Hello,
>
> Sorry , here is the right link, the gcc -ftrapv is not good, read here:

What do you think you're playing at? Enough already!

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

comp.programming

Read again about my objection about C++ and C

Ramine

Richard Heathfield

Öö Tiib

kenobi

Richard Heathfield

Richard Heathfield

Richard Heathfield

Richard Heathfield

Richard Heathfield

Richard Heathfield

Richard Heathfield

x Login to ForumsZone