Read again about my objection about C++ and C

[Ramine]

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_Overloading_(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.

[Ramine]

Here is my answer to Richard Heatfield on comp.programming:

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.
>

[Prroffessorr Fir Kenobi]

ram,
you said once ago that that post you wrote
was your last one - why you lie to us poor fella?