Discussion:
About C++ again..
Add Reply
Sky89
2018-08-04 05:03:59 UTC
Reply
Permalink
Raw Message
Hello...

Read this:


About C++ again..

I have just checked CPPCheck here:

http://cppcheck.sourceforge.net/


And this static analyser has the same problem, it doesn't prevent
many "dangerous" implicit operations..

And I said before that type-safety of C++ is not good by default:

Here is my proof: look at this library that is "trying"(But it is
not yet sufficient) to improve the type-safety of C++:

Improve Type Safety in Your C++ Program With the type_safe Library

"Features provided by the type_safe library include improved built-in
types (ts::integer, ts::floating_point, and ts::boolean) which prevent
dangerous implicit operations like signed-to-unsigned promotion."

Read more here:

https://embeddedartistry.com/blog/2018/5/24/improve-type-safety-in-your-c-program-with-the-typesafe-library


This is why i said before the following:

Also I will not waste my time with C++, because from the start C++ was
handicaped, because it has inherited the deficiencies of C, i think C is
"not" a good programming language because it is "too" weakly typed and
it allows implicit type conversions that are bad for reliability etc.
and this looks like the mess of assembler, because C was "too" low level
for reliability, and since C++ has inherited from C, C++ has inherited
this too low level parts that are not good for reliability, so i will
not waste my time with C++ or with C, and i will continu to code in
"modern" Object Pascal of Delphi and FreePascal that is more
conservative because it has a "decent" reliability and a "decent"
performance, and those Delphi and FreePascal compilers are "powerful"
today. And i will also work with "Java", because Mono is not following
fast the developement of C# and it is not as portable as Java.

And here is what i wrote about C++ and Delphi and FreePascal and ADA:

Energy efficiency isn’t just a hardware problem. Your programming
language choices can have serious effects on the efficiency of your
energy consumption. We dive deep into what makes a programming language
energy efficient.

As the researchers discovered, the CPU-based energy consumption always
represents the majority of the energy consumed.

What Pereira et. al. found wasn’t entirely surprising: speed does not
always equate energy efficiency. Compiled languages like C, C++, Rust,
and Ada ranked as some of the most energy efficient languages out there.

Read more here:

https://jaxenter.com/energy-efficient-programming-languages-137264.html

RAM is still expensive and slow, relative to CPUs

And "memory" usage efficiency is important for mobile devices.

So Delphi and FreePascal compilers are also still "useful" for mobile
devices, because Delphi and FreePascal are good if you are considering
time and memory or energy and memory, and the following pascal benchmark
was done with FreePascal, and the benchmark shows that C, Go and Pascal
do rather better if you’re considering languages based on time and
memory or energy and memory.

Read again here to notice it:

https://jaxenter.com/energy-efficient-programming-languages-137264.html


Also Delphi is still better for many things, and you have to get more
"technical" to understand it, this is why you have to look at this
following video about Delphi that is more technical:

Why are C# Developers choosing Delphi to create Mobile applications




And I think there is still a "big" problem with C++ and C..

Look at C++ explicit conversion functions, they were introduced in
C++11, but this doesn't come by "default" in C++, like in modern Object
Pascal of Delphi and FreePascal and like in ADA , because in C++ you
have to write explicit conversion functions etc., so this is not good
for reliability in C++, and C++ doesn't by "default" come with range
checking and Run-time checks that catch conversion from negative signed
to unsigned and arithmetic overflow , you have for example to add and
use SafeInt library for that, and C++ doesn't by "default" catch
out-of-bounds indices of dynamic and static arrays this is why C++ is
not good for reliability.

But Delphi and FreePascal like ADA come with range checking and Run-time
checks that catch conversion from negative signed to unsigned , and
catch out-of-bounds indices of dynamic and static arrays and catch
arithmetic overflow etc. and you can also dynamically catch this
exception of ERangeError etc. and they do not allow those bad
implicit type conversions of C++ that are not good for reliability.

And you can carefully read the following, it is very important:

https://critical.eschertech.com/2010/07/07/run-time-checks-are-they-worth-it/


And about Escher C++ Verifier, read carefully:

"Escher C Verifier enables the development of formally-verifiable
software in a subset of C (based on MISRA-C 2012)."

Read here:

http://www.eschertech.com/products/index.php


So it verifies just a "subset" of C, so that's not good for C++
because for other applications that are not a subset of C , it can
not do for example Run-time checks, so we are again into
this problem again that C++ and C don't have range checking and many
Run-time checks, so that's not good in C++ and C because it is not good
for reliability and it is not good for safety-critical systems.


So for all the reasons above , i think i will stop coding in C++ and
i will quit C++.



Thank you,
Amine Moulay Ramdane.
M***@thruhikinggear.com
2018-08-04 18:10:02 UTC
Reply
Permalink
Raw Message
Post by Sky89
Hello...
About C++ again..
http://cppcheck.sourceforge.net/
And this static analyser has the same problem, it doesn't prevent
many "dangerous" implicit operations..
Here is my proof: look at this library that is "trying"(But it is
Improve Type Safety in Your C++ Program With the type_safe Library
"Features provided by the type_safe library include improved built-in
types (ts::integer, ts::floating_point, and ts::boolean) which prevent
dangerous implicit operations like signed-to-unsigned promotion."
https://embeddedartistry.com/blog/2018/5/24/improve-type-safety-in-your-c-program-with-the-typesafe-library
Also I will not waste my time with C++, because from the start C++ was
handicaped, because it has inherited the deficiencies of C, i think C is
"not" a good programming language because it is "too" weakly typed and
it allows implicit type conversions that are bad for reliability etc.
and this looks like the mess of assembler, because C was "too" low level
for reliability, and since C++ has inherited from C, C++ has inherited
this too low level parts that are not good for reliability, so i will
not waste my time with C++ or with C, and i will continu to code in
"modern" Object Pascal of Delphi and FreePascal that is more
conservative because it has a "decent" reliability and a "decent"
performance, and those Delphi and FreePascal compilers are "powerful"
today. And i will also work with "Java", because Mono is not following
fast the developement of C# and it is not as portable as Java.
Energy efficiency isn’t just a hardware problem. Your programming
language choices can have serious effects on the efficiency of your
energy consumption. We dive deep into what makes a programming language
energy efficient.
As the researchers discovered, the CPU-based energy consumption always
represents the majority of the energy consumed.
What Pereira et. al. found wasn’t entirely surprising: speed does not
always equate energy efficiency. Compiled languages like C, C++, Rust,
and Ada ranked as some of the most energy efficient languages out there.
https://jaxenter.com/energy-efficient-programming-languages-137264.html
RAM is still expensive and slow, relative to CPUs
And "memory" usage efficiency is important for mobile devices.
So Delphi and FreePascal compilers are also still "useful" for mobile
devices, because Delphi and FreePascal are good if you are considering
time and memory or energy and memory, and the following pascal benchmark
was done with FreePascal, and the benchmark shows that C, Go and Pascal
do rather better if you’re considering languages based on time and
memory or energy and memory.
https://jaxenter.com/energy-efficient-programming-languages-137264.html
Also Delphi is still better for many things, and you have to get more
"technical" to understand it, this is why you have to look at this
Why are C# Developers choosing Delphi to create Mobile applications
http://youtu.be/m8ToSr4zOVQ
And I think there is still a "big" problem with C++ and C..
Look at C++ explicit conversion functions, they were introduced in
C++11, but this doesn't come by "default" in C++, like in modern Object
Pascal of Delphi and FreePascal and like in ADA , because in C++ you
have to write explicit conversion functions etc., so this is not good
for reliability in C++, and C++ doesn't by "default" come with range
checking and Run-time checks that catch conversion from negative signed
to unsigned and arithmetic overflow , you have for example to add and
use SafeInt library for that, and C++ doesn't by "default" catch
out-of-bounds indices of dynamic and static arrays this is why C++ is
not good for reliability.
But Delphi and FreePascal like ADA come with range checking and Run-time
checks that catch conversion from negative signed to unsigned , and
catch out-of-bounds indices of dynamic and static arrays and catch
arithmetic overflow etc. and you can also dynamically catch this
exception of ERangeError etc. and they do not allow those bad
implicit type conversions of C++ that are not good for reliability.
https://critical.eschertech.com/2010/07/07/run-time-checks-are-they-worth-it/
"Escher C Verifier enables the development of formally-verifiable
software in a subset of C (based on MISRA-C 2012)."
http://www.eschertech.com/products/index.php
So it verifies just a "subset" of C, so that's not good for C++
because for other applications that are not a subset of C , it can
not do for example Run-time checks, so we are again into
this problem again that C++ and C don't have range checking and many
Run-time checks, so that's not good in C++ and C because it is not good
for reliability and it is not good for safety-critical systems.
So for all the reasons above , i think i will stop coding in C++ and
i will quit C++.
Thank you,
Amine Moulay Ramdane.
Thanks for sharing. It's very interesting.

Loading...