Wednesday, December 30, 2015

Digest for comp.lang.c++@googlegroups.com - 12 updates in 6 topics

Ramine <ramine@1.1>: Dec 30 03:08PM -0800

Hello....
 
 
I think C++ is good for realtime safety critical systems, because:
 
 
1- You can enforce the strong typing of Ada by using
object oriented programming.
 
2- And you can avoid signed or unsigned int overflow and underflow by
using a secure library that uses operator overloading with
the right tests inside them that catch the signed or unsigned int
overflow and underflow.
 
 
So the case is closed ! so i am convinced now that C++ is good for
realtime safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
bleachbot <bleachbot@httrack.com>: Dec 30 07:40PM +0100

bleachbot <bleachbot@httrack.com>: Dec 30 08:04PM +0100

bleachbot <bleachbot@httrack.com>: Dec 30 09:00PM +0100

bleachbot <bleachbot@httrack.com>: Dec 30 09:07PM +0100

Ramine <ramine@1.1>: Dec 30 03:01PM -0800

Hello.....
 
 
I think C++ is good for reatime safety critical systems, because:
 
 
1- You can enforce the strong typing of Ada by using
object oriented programming.
 
2- And you can avoid signed or unsigned int overflow and underflow by
using a secure library that uses operator overloading with
the right tests inside them that catch the signed or unsigned int
overflow and underflow.
 
 
So the case is claused ! so i am convinced now that C++ is good for
reatime safety critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Dec 30 01:40PM -0800

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 <ramine@1.1>: Dec 30 02:04PM -0800

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:
Prroffessorr Fir Kenobi <profesor.fir@gmail.com>: Dec 30 11:44AM -0800

ram,
you said once ago that that post you wrote
was your last one - why you lie to us poor fella?
BartC <bc@freeuk.com>: Dec 30 12:11PM

On 26/12/2015 10:15, Paavo Helde wrote:
> 'length' to 'weight'
> 1> No user-defined-conversion operator available that can
> perform this conversion, or the operator cannot be called
 
The C++ version is defining structs not scalars? If I try this:
 
length x,y,z;
 
x = y+z;
 
it fails. So does simply writing x=0.0 (or x=(length)0.0).
 
No doubt there are ways to make all this stuff work in C++, but you have
to do that work, and the resultant type safety depends on how well that
is done.
 
(x=y*z would also fail, but probably not for the right reasons! I'm not
sure whether even Ada would deal with that correctly without extra work.)
 
--
Bartc
 
 
 
 
 
 
 
"Öö Tiib" <ootiib@hot.ee>: Dec 30 09:31AM -0800

On Wednesday, 30 December 2015 14:12:05 UTC+2, BartC wrote:
> > 1> No user-defined-conversion operator available that can
> > perform this conversion, or the operator cannot be called
 
> The C++ version is defining structs not scalars?
 
No. The example was how to make context-aware types and not to
use scalars directly. The 'struct' in C++ denotes a class whose base
classes and members are implicitly 'public'. Otherwise 'struct weight'
and 'class weight' are synonymous in C++.
 
 
> length x,y,z;
 
> x = y+z;
 
> it fails. So does simply writing x=0.0 (or x=(length)0.0).
 
So what is bad? Defects have been detected compile time. Either illegal
operations are used on 'length' objects or interface of 'length' class is
incomplete.
 
 
> No doubt there are ways to make all this stuff work in C++, but you have
> to do that work, and the resultant type safety depends on how well that
> is done.
 
Correctness of all software depends on how well it is written.
 
 
> (x=y*z would also fail, but probably not for the right reasons! I'm not
> sure whether even Ada would deal with that correctly without extra work.)
 
It will fail also for the very same right reasons: illegal operations are rejected
or interface of class 'length' is incomplete and defect is detected compile
time. The defect can be also as simply fixed:
 
#include <iostream>
 
struct length { float value; };
struct area { float value; };
 
area operator*(length x, length y) {return area{x.value * y.value};}

int main()
{
length x{3.4}, y{5.6};

// length z = x * y; <- ERROR: can't convert area to length

area S = x * y; // <- FINE: S is 19.04
 
std::cout << S.value << "\r";
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 30 11:51AM +0100

I've done a bit more coding on (this re-creation of) the cppx
header-only library, at
 

https://github.com/alf-p-steinbach/cppx/commit/bf1081a6e5465d1dd0265f9dca9ba6d20cd288f1
 
so that the following works nicely in Windows:
 
 
<code>
#include <p/cppx/basics.hpp>
using namespace std;
namespace cppx = progrock::cppx;
 
void cpp_main()
{
using cppx::sys;
using cppx::String;
sys.out << "Using cppx version " << cppx::version_cstring << "." <<
endl;
sys.out << endl;
 
sys.out << "Direct output of narrow literal : "
<< "• "blåbærsyltetøy"." << endl;
 
sys.out << "Widened at compile time (in Windows): "
<< CPPX_RAW_SYSTEXT( "• "blåbærsyltetøy"." ) << endl;
 
sys.out << "Widened at runtime (in Windows) : "
<< String( "• "blåbærsyltetøy"." ) << endl;
}
</code>
 
 
The extra indirection via sys.out means that it should work nicely also
in Unix-land, when I get to that. In Windows sys.out is a reference to
wcout, while in Unix-land & elsewhere it's a reference to cout. And in
Windows those streams are configured to use Unicode, so that the output
from the above is not the usual gobbledegook, but like this:
 
 
<output>
Using cppx version 2015-12-30.
 
Direct output of narrow literal : • "blåbærsyltetøy".
Widened at compile time (in Windows): • "blåbærsyltetøy".
Widened at runtime (in Windows) : • "blåbærsyltetøy".
</output>
 
 
The strange result with the direct output of narrow literal is
consistent with replacing every non-Latin-1 character with something.
That could happen if the internal translation (from Windows ANSI Western
to UTF-16) in Microsoft's stream implementation just copies the
character codes blindly. But I'm not sure what really goes on inside the
stream, it's just an hypothesis that matches the data so far.
 
Input is a more complicated. I remember that g++ used to produce
double-spaced input, with every second line blank, and I have a fix for
that somewhere. Unless they've fixed the g++ library implementation now.
 
 
Anyway, cheers!, enjoy, and Happy New Year coming up!,
 
- Alf
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)