Saturday, May 19, 2018

Digest for comp.programming.threads@googlegroups.com - 15 updates in 15 topics

Sky89 <Sky89@sky68.com>: May 18 10:45PM -0400

Hello....
 
 
Sorry i correct..
 
To be more precise...
 
 
C++ and Delphi and FreePascal can approximate better the safety
of Rust by using more tools, and i have given you a solution of that in
my previous posts that uses variants to emulate strict-type safety of
Rust, so from this we can affirm that the sum of mean time between
failures will become much more big using those methods, so that it can
save us more money for example.
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 10:31PM -0400

Hello....
 
 
To be more precise...
 
 
C++ and Delphi and FreePascal can approximate better the safety
of Rust by using more tools, and i have given you a solution of that in
my previous posts that uses variants to emulate strict-type safety of
Rust, so from this we can affirm that the sum of mean time between
failures will become much more small using those methods, so that it can
save us more money for example.
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 10:11PM -0400

Hello...
 
 
I think that Rust will not Win, because Rust is especially
designed for very high safety that is needed for safety-critical
systems, so it can win on safety-critical systems, but it can
not win Java and it can not win even C++ because not everyone needs this
kind of very high safety of Rust. So we can continu to program and love
Delphi and FreePascal and C++ and Java.
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 09:50PM -0400

Hello...
 
 
I think Rust is "restrictive" to be able to be more disciplined , so
that to be more reliability. This the game of Rust.
 
C++ is more "permissive" by being it more weakly typed etc.
and this is not good for reliability.
 
Rust will win, because Rust is much better for reliability and
for Safety-critical systems.
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 09:39PM -0400

Hello..
 
 
About discipline and reliability: we have to adopt Rust, Rust is
designed for discipline and reliability, C++ is less reliability than
Rust and it can not compete with Rust.
 
I think from now on, i will start also to program in Rust.
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 09:27PM -0400

Hello...
 
 
About Rust and Spark and C++
 
I think Rust and Spark "enforce" discipline with strict-type safety and
static and dynamic checks for more reliability and this is good for
Safety-critical systems
 
But C++ is more "permissive" with being it more weakly typed etc. and
this is not good for Safety-critical systems.
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 09:06PM -0400

Hello..
 
 
I wrote before this:
 
Also read this about Software reliability:
 
"Both Rust and Spark languages implement a number of static and dynamic
checks directly in the language definition. For example, they implement
strict-type safety; that is, objects can't be implicitly converted from
one type to the next. The following doesn't compile in SPARK"
 
 
Read more here:
 
http://www.electronicdesign.com/industrial/rust-and-spark-software-reliability-everyone
 
 
I think C++Builder has a good implementation of variants that allows
you to "emulate" much better strict-type safety of Rust and Spark,
i have looked to Boost variants and i think it is less powerful
than the one in C++Builder, here is how you have to extend
type-safety, you realize this solution with objects that contains
variants that represent different types and the functions that work with
them like Add and Multiply and Divide etc, here is the solution
for FreePascal and Delphi and C++Builder and you can extend
it, so i think FreePascal and Delphi and C++Builder are now acceptable
for more reliability:
 
--
 
program test;
 
uses VARIANTS,SYSUTILS;
 
var f:double;
a:integer;
 
 
 
FUNCTION ASSIGN(a,B:VARIANT):VARIANT;
 
begin
 
IF VARTYPE(A)=VARTYPE(B) THEN
BEGIN
A:=B;
RESULT:=A;
END
ELSE RAISE EXCEPTION.CREATE('ASSIGNEMENT NOT OK');
 
 
end;
 
begin
 
a:=2;
 
f:=a;
 
A:=ASSIGN(F,A);
 
 
end.
--
 
 
Here is the Vartype function:
 
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/Variants_VarType.html
 
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 08:31PM -0400

Hello....
 
 
Read again, i correct some typos because i write fast:
 
We have to be more smart about C++
 
I think that C++ as it is, is not well suited for realtime systems
and realtime critical systems.. you have to add over it
Extended static checking (ESC) etc. so that C++ be acceptable
or here is one of my other solution to the problem that i have
talked about: As you have noticed i have spoken before about the how to
disallow conversion from negative signed to positive unsigned, here is
my solution with variants, also you can extend this solution with
objects that contains variants that represent different types and the
functions that work with them like Add and Multiply and Divide etc :
 
 
Here is the solution that works also with C++Builder , since
C++Builder has a good implementation of variants
 
As you know i am working with Delphi and FreePascal and C++..
 
And now about Software Reliability:
 
Extended static checking (ESC) can identify a range of errors which are
currently outside the scope of a type checker, including division by
zero, array out of bounds, integer overflow and null dereferences,
this can be done with Delphi and FreePascal compilers.
 
Furthermore, extended static checking aims to report errors by
exploiting user-supplied specifications, in the form of pre- and
post-conditions, loop invariants and class invariants, this can
be done by assertions in Delphi and FreePascal.
 
Read more here:
 
http://whiley.org/2010/06/26/what-is-extended-static-checking/
 
 
Also read this about Software reliability:
 
"Both Rust and Spark languages implement a number of static and dynamic
checks directly in the language definition. For example, they implement
strict-type safety; that is, objects can't be implicitly converted from
one type to the next. The following doesn't compile in SPARK"
 
 
Read more here:
 
http://www.electronicdesign.com/industrial/rust-and-spark-software-reliability-everyone
 
 
Here is how you can have strict-type safety in Delphi and FreePascal,
here is a Delphi program that shows an example using variants:
 
--
 
program test;
 
uses VARIANTS,SYSUTILS;
 
var f:double;
a:integer;
 
 
 
FUNCTION ASSIGN(a,B:VARIANT):VARIANT;
 
begin
 
IF VARTYPE(A)=VARTYPE(B) THEN
BEGIN
A:=B;
RESULT:=A;
END
ELSE RAISE EXCEPTION.CREATE('ASSIGNEMENT NOT OK');
 
 
end;
 
begin
 
a:=2;
 
f:=a;
 
A:=ASSIGN(F,A);
 
 
end.
--
 
 
Here is the Vartype function:
 
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/Variants_VarType.html
 
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 08:23PM -0400

Hello...
 
 
We have to be more smart about C++
 
I think that C++ as it is, is not well suited for realtime systems
and realtime critical systems.. you have to add over it
Extended static checking (ESC) etc. so that C++ be acceptable
or here is one of my other solution to the problem that i have
talked about: As you have noticed i have spoken before about the how to
disallow conversion from negative signed to positive unsigned, here is
my solution with variants, also you can extend this solution with
objects contains variants that represent different types and the
functions that works with them like Add and Multiply and Divide etc :
 
 
Here is the solution that works also with C++Builder , since
C++Builder has a good implementation of variants
 
As you know i am working with Delphi and FreePascal and C++..
 
And now about Software Reliability:
 
Extended static checking (ESC) can identify a range of errors which are
currently outside the scope of a type checker, including division by
zero, array out of bounds, integer overflow and null dereferences,
this can be done with Delphi and FreePascal compilers.
 
Furthermore, extended static checking aims to report errors by
exploiting user-supplied specifications, in the form of pre- and
post-conditions, loop invariants and class invariants, this can
be done by assertions in Delphi and FreePascal.
 
Read more here:
 
http://whiley.org/2010/06/26/what-is-extended-static-checking/
 
 
Also read this about Software reliability:
 
"Both Rust and Spark languages implement a number of static and dynamic
checks directly in the language definition. For example, they implement
strict-type safety; that is, objects can't be implicitly converted from
one type to the next. The following doesn't compile in SPARK"
 
 
Read more here:
 
http://www.electronicdesign.com/industrial/rust-and-spark-software-reliability-everyone
 
 
 
Here is how you can have strict-type safety in Delphi and FreePascal,
here is a Delphi program that shows an example using variants:
 
--
 
program test;
 
uses VARIANTS,SYSUTILS;
 
var f:double;
a:integer;
 
 
 
FUNCTION ASSIGN(a,B:VARIANT):VARIANT;
 
begin
 
IF VARTYPE(A)=VARTYPE(B) THEN
BEGIN
A:=B;
RESULT:=A;
END
ELSE RAISE EXCEPTION.CREATE('ASSIGNEMENT NOT OK');
 
 
end;
 
begin
 
a:=2;
 
f:=a;
 
A:=ASSIGN(F,A);
 
 
end.
--
 
 
Here is the Vartype function:
 
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/Variants_VarType.html
 
 
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 06:33PM -0400

Hello..
 
 
I think you know me more today, i program in Delphi and FreePascal, and
in FreePascal i program in the Delphi "mode" too, so as you have noticed
i am not programming in pascal, i am programming in "modern" Object
Pascal that is "much" more powerful than pascal, this is why i love
Delphi and FreePascal and Lazarus too that uses FreePascal, and as you
have noticed i have made Delphi and FreePascal better by for example
inventing "scalable" algorithms and implementing them in Delphi and
FreePascal, and as you have noticed my work is a more serious work,
and to notice it please look for example at my last invention in Delphi
and FreePascal here:
 
Here is my last invention for Delphi and FreePascal:
 
Scalable reference counting with efficient support for weak references
 
https://sites.google.com/site/aminer68/scalable-reference-counting-with-efficient-support-for-weak-references
 
As you have noticed my inventions that are my scalable algorithms have
enhanced much more Delphi and FreePascal, this is why i am here to make
Delphi and FreePascal better, i don't like C++ or C, because as
i have explained in my previous posts, they are too weakly typed,
they are not like modern Object Pascal of Delphi and FreePascal that
is more strongly typed than C++ or C , that means it is more safer in
this matter, and since ADA looks a lot like Delphi and FreePascal,
so i think i will port some of my projects to ADA, because i have
looked at ADA and ADA is easy for me.
 
 
You will find my others inventions(that are my scalable algorithms
implementations) and my other software projects here:
 
https://sites.google.com/site/aminer68/
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 05:51PM -0400

Hello....
 
 
Read again, i correct a typo , because i write fast..
 
I come from Delphi and Freepascal, and i have looked at ADA, and
ADA is easy for me, i have done also some C++ , but C++ is "too"
weakly typed as i have explained in my previous posts, this is why i
love ADA, because ADA is more strongly typed than C++ or C , it looks
like Delphi and FreePascal. I love ADA because i love Delphi and FreePascal.
 
Here is my last invention for Delphi and FreePascal:
 
Scalable reference counting with efficient support for weak references
 
https://sites.google.com/site/aminer68/scalable-reference-counting-with-efficient-support-for-weak-references
 
 
You can find my other "inventions" and my other projects here:
 
https://sites.google.com/site/aminer68/
 
 
Thank youk,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 05:25PM -0400

Hello..
 
More about the deficiency of C++
 
If you want to assign a negative signed variable to a positive unsigned
variable, this is possible in C++ and C.
 
And this is not possible in Delphi and FreePascal (with range checking
enabled) and it is not possible with ADA because they are strongly typed.
 
Also:
 
I have just tested C++ , and when i instantiate an object and i want to
assign the object to a variable, the C++ is weakly typed , so it can
assign a type of an object to another type of a variable, and this
is a big problem ! C++ has inherited this deficiency of being
"too" weakly typed from C, Delphi and FreePascal that i work with are
more strongly typed and they will not allow this problem to happen, ADA
too is strongly typed and it will not allow this problem to happen.
 
 
So from the above reasons i think that C++ and C are "too" permissive
and "too" weakly typed, they are more unsafe than ADA or Delphi or
FreePascal.
 
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 04:50PM -0400

Hello..
 
 
About the deficiency of C++
 
I have just tested C++ , and when i instantiate an object and i want to
assign the object to a variable, the C++ is weakly typed , so it can
assign a type of an object to another type of a variable, and this
is a big problem ! C++ has inherited this deficiency of being
"too" weakly typed from C, Delphi and FreePascal that i work with are
more strongly typed and they will not allow this problem to happen, ADA
too is strongly typed and it will not allow this problem to happen.
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 04:05PM -0400

Hello,
 
 
A good book on C++:
 
Beginning C++17
From Novice to Professional
 
https://www.apress.com/us/book/9781484233658
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 18 03:37PM -0400

Hello,
 
 
C++ and Thoughts On Java, Go, and Rust:
 
https://eklitzke.org/c++-java-go-and-rust
 
 
 
Thank you,
Amine Moulay Ramdane.
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.programming.threads+unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)