Hello..
More about FreePascal and Delphi and C# and Java, read all the following:
C#, is a slightly higher level language than C++ or Delphi or
FreePascal. Its requirement of managed runtime environment means that
you wont be able to write an operating system, or even a device driver,
in it. This sort of area is typically known as systems programming(with
C++ or Delphi or FreePascal etc.).
And what about garbage collection?
Read what said Chris Lattner:
"One thing that I don’t think is debatable is that the heap compaction
behavior of a GC (which is what provides the heap fragmentation win) is
incredibly hostile for cache (because it cycles the entire memory space
of the process) and performance predictability."
"Not relying on GC enables Swift to be used in domains that don’t want
it - think boot loaders, kernels, real time systems like audio
processing, etc."
"GC also has several *huge* disadvantages that are usually glossed over:
while it is true that modern GC's can provide high performance, they can
only do that when they are granted *much* more memory than the process
is actually using. Generally, unless you give the GC 3-4x more memory
than is needed, you’ll get thrashing and incredibly poor performance.
Additionally, since the sweep pass touches almost all RAM in the
process, they tend to be very power inefficient (leading to reduced
battery life)."
Read more here:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html
Here is Chris Lattner's Homepage:
http://nondot.org/sabre/
And here is Chris Lattner's resume:
http://nondot.org/sabre/Resume.html#Tesla
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
https://www.youtube.com/watch?v=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.
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.