Thursday, November 11, 2021

Digest for comp.lang.c++@googlegroups.com - 17 updates in 7 topics

olcott <NoOne@NoWhere.com>: Nov 11 01:30PM -0600

On 11/11/2021 1:20 PM, Richard Damon wrote:
 
> Thus, there ARE NO 'C aspects' of this 'program' as the C standard has
> declared that it suppies NO definition of what it does.
 
> FAIL.
 
I added this: #include <stdint.h>
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Richard Damon <Richard@Damon-Family.org>: Nov 11 02:38PM -0500

On 11/11/21 2:30 PM, olcott wrote:
>> declared that it suppies NO definition of what it does.
 
>> FAIL.
 
> I added this: #include <stdint.h>
 
But it still fails and will get a mandatory diagnostic, and the
execution is undefined. P can not use the symbol H without it being
prior declaired in any version of C that defines uintptr_t.
 
You either need the definition of H before the definition of P or you
need a forward decleration for the function H before the call.
 
C90 allowed this, which is why you may be just getting a warning, but
the actual meaning is that the C Standard has disavowed any definition
to the program.
 
And, all this shows is that for a H that just calls its input, you do
get an infinite recursion, but such an H never gives the answer about it.
 
Since the behavior of P depends on the behavior of H, if you change H to
be able to give an answer, you have changed the behavior of P so you
'proof' doesn't apply any more.
 
Show your level of skill as a junior programmer.
olcott <NoOne@NoWhere.com>: Nov 11 01:59PM -0600

On 11/11/2021 1:38 PM, Richard Damon wrote:
> prior declaired in any version of C that defines uintptr_t.
 
> You either need the definition of H before the definition of P or you
> need a forward decleration for the function H before the call.
 
#include <stdint.h>
#define ptr uintptr_t
 
int H(ptr x, ptr y)
{
((void(*)(ptr))x)(y);
return 1;
}
 
void P(ptr x)
{
H(x, x);
}
 
int main()
{
H((ptr)P, (ptr)P);
return 0;
}
 
I embedded the above in a whole other program so these "errors"
were corrected in code that I did not know about.
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Richard Damon <Richard@Damon-Family.org>: Nov 11 03:11PM -0500

On 11/11/21 2:59 PM, olcott wrote:
 
> I embedded the above in a whole other program so these "errors"
> were corrected in code that I did not know about.
 
In other words, you don't know how to do a controlled experiment so we
really need to deman FULL disclosure of exactly what you are doing
before we can accept any 'experimental' evidence.
 
You are writing your obituary here.
olcott <NoOne@NoWhere.com>: Nov 11 02:16PM -0600

On 11/11/2021 2:11 PM, Richard Damon wrote:
> really need to deman FULL disclosure of exactly what you are doing
> before we can accept any 'experimental' evidence.
 
> You are writing your obituary here.
 
Don't say that. I have terminal cancer in its advanced stages.
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 11 08:25PM

>> And well, H calls P and P calls H. What do you expect?
 
> However many programing languages allow 'mutual recursion" and it's
> very useful.
 
Just in case there is any confusion, both C and C++ allow mutual
recursion.
 
--
Ben.
Jeff Barnett <jbb@notatt.com>: Nov 11 02:55PM -0700

On 11/11/2021 12:26 PM, olcott wrote:
> On 11/11/2021 1:06 PM, Jeff Barnett wrote:
 
<SNIP>
 
 
> (Attacking the person): This fallacy occurs when, instead of addressing
> someone's argument or position, you irrelevantly attack the person or
> some aspect of the person who is making the argument.
 
I was not attacking your argument; I was attacking you as a demonstrable
idiot. Therefore this was/is not an example of Ad Hominem argument. You
are nuts, you are lonesome, you are making a bid for attention, and the
quality of the interaction, no matter how negative, is what you grave.
All facts. Find a qualified mental health professional, show them your
posts - any half dozen or so will do - and ask for an evaluation. I bet
they wont let you leave the office without a lifetime prescription for
"happy" pills.
 
Most of my message was to Mueller about relative approaches to mutual
recursion in different languages. In fact what I said, technically,
might have been a slight defense of your abysmal code. There is no straw
man here unless it was you with straw in your head for brains. You
really should read and understand before criticizing.
 
I haven't ask you this for a long time but I think it is appropriate
now: Are you typing with one hand in your pants, playing with yourself?
Your not very good at multitasking; so one thing at a time. Go slow,
very slow else you will out run your brain.
--
Jeff Barnett
olcott <NoOne@NoWhere.com>: Nov 11 04:11PM -0600

On 11/11/2021 1:06 PM, Jeff Barnett wrote:
 
>> And well, H calls P and P calls H. What do you expect?
> I expect that PO (the OP) is nuts and lonesome.
 
> This crap is just
 
A conclusion was formed about the quality of my work and the only basis
provided for this conclusion was the personal attack that preceded it.
 
> debugging as well as mutual recursion.
 
> And as an aside, I think that Common LISP has at least as flexible and
> powerful an object system as does any of the C variants.
 
This is an example of the strawman error in that the concrete code that
I precisely specified never halts because of infinite recursion.
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
olcott <NoOne@NoWhere.com>: Nov 11 04:51PM -0600

On 11/11/2021 3:55 PM, Jeff Barnett wrote:
>> person or some aspect of the person who is making the argument.
 
> I was not attacking your argument; I was attacking you as a demonstrable
> idiot. Therefore this was/is not an example of Ad Hominem argument. You
 
 
On 11/11/2021 1:06 PM, Jeff Barnett wrote:
> I expect that PO (the OP) is nuts and lonesome.
 
> This crap is just
 
a conclusion about the quality of my work that only has the personal
attack that precedes it as its basis.
 
 
--
Copyright 2021 Pete Olcott
 
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 02:43PM -0800

Hello,
 
 
 
More of my philosophy about Python and Ruby and Go languages and more..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think i am smart since i am an inventor of many powerful scalable algorithms, so i am specialized in parallel programming and synchronization algorithms, and i say that Python and Ruby and Go
languages have a big problem, and it is that Python can use python interpreters in each process or in each thread so that to avoid to lock in a single interpreter, but this brings a big problem and it is that you have to transfer the data of the inside of a python object between threads or processes using a queue or shared memory etc. and it doesn't look like C++ or Delphi way where you can move a pointer or reference to an object not the data inside an object between threads so that to scale and be fast, so this way of moving data of inside an object of Python and Ruby is not scalable and is too slow and it looks like MPI messaging way, Go language has not this big problem but Go has the same problem as Rust since it doesn't provide us with OOP inheritance, read about it in my following thoughts:
 
More of my philosophy about the too much purism philosophy of Rust and more..
 
I think i am smart, and i think that Rust compiler and language is too much "purist", it looks like the too much purism of Haskell functional programming language, since i say that Rust doesn't provide us with OOP inheritance, but it is too much restrictive, and it is the deficiency of Rust, since inheritance has advantages and disadvantages, so we have to balance well and provide also with inheritance so that to be efficient, so i think that C++ and C# are better than Rust in this regard, and here is the advantages and disadvantages of OOP inheritance:
 
https://www.ianswer4u.com/2017/09/oops-inheritance-advantages.html
 
More of my philosophy about NP-hard problems and about Rust and C++..
 
I think i am smart and i have just quickly looked at Rust compiler and i think that since the Rust compiler has included race detection so
it is NP-hard, so that means that Rust compiler will never know in race detection which of races are real race conditions(Read here in the following paper so that to understand it: https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf), and, this is the reason why it is difficult to use a tool to find race conditions accurately, so then i think that C++ is still useful by using it with Threadsanatizer and Address sanatizer even if C++ is getting complex as i just said the following:
 
Also C++ has the following problem:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Nov 11 08:47PM +0100

On 11 Nov 2021 07:36, Bonita Montero wrote:
>> Conversely, when you use `>>` you can let `>>` parse the input.
>> I see no advantage in both using `>>` and parsing the input.
 
> How get parsing-errors signalled when using getline […]
 
#include <iostream>
#include <charconv>
#include <optional>
#include <string>
#include <string_view>
using namespace std;
 
auto parse_double( const string_view s )
-> optional<double>
{
const auto p_begin = s.data();
const auto p_end = p_begin + s.size();
double value;
const from_chars_result fcr = from_chars( p_begin, p_end, value );
if( fcr.ec != errc() or fcr.ptr < p_end ) { return {}; }
return value;
}
 
int main()
{
cout << "Enter a number: " ;
string s;
getline( cin, s );
if( const optional<double> parsed = parse_double( s ) ) {
cout << "You entered: " << parsed.value() << endl;
return EXIT_SUCCESS;
}
cout << "Invalid value." << endl;
return EXIT_FAILURE;
}
 
 
> […] or operator >> ?
 
#include <ctype.h>
 
#include <charconv>
#include <limits>
#include <iostream>
#include <limits>
#include <optional>
using namespace std;
 
auto input_double()
-> optional<double>
{
double value;
cin >> value;
const bool ok = (not cin.fail()) and ::isspace(cin.peek());
cin.clear();
return (ok? optional<double>( value ) : nullopt);
};
 
int main()
{
cout << "Enter a number: " ;
if( const optional<double> parsed = input_double() ) {
cout << "You entered: " << parsed.value() << endl;
return EXIT_SUCCESS;
}
cout << "Invalid value." << endl;
return EXIT_FAILURE;
}
 
 
As presented the only difference is that with `getline` one deals with
and consumes one line of input at a time, whereas with `>>` one deals
with and consumes one whitespace-separated "word" of input at a time.
 
However, when code maintenance introduces a little `setlocale` the
`getline` + `from_chars` parsing will still use '.' as fractional part
delimiter, whereas the `>>` code may then use ',' as delimiter. Which is
part of the reason for C++17 introduction of `from_chars`.
 
So, it's not perfect.
 
 
- Alf
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Nov 11 08:35PM

On 10/11/2021 08:50, Joseph Hesse wrote:
>   PrintBuffer(cin);
>   return 0;
> }
 
Maybe you've misunderstood what rdbuf() is doing. It returns a pointer
to the stream's (cin's) internal basic_streambuf object. When you pipe
this to cout, effectively you are copying one stream (stdin) to the
other (stdout). Characters will be read from the basic_streambuf and
written to cout, continuing until EOF is encountered. (I.e. the
basic_streambuf represents the full stream from stdin, not just some
portion which is currently in memory...)
 
So that explains why the program hangs - it's waiting for more input.
Also that's why you don't see the "--" or final newline. You could
enter control-Z to terminate stdin, and you'd see the missing output,
but that's probably not what you want.
 
Others have suggested what is mostly alternative ways of parsing stuff.
If you want to pursue your original intention, just fixing the bug, then
you don't want to pipe the whole stdin stream into cout! One approach
would be to read one line of input to a string, then create a
istringstream on the string buffer for testing your extract operations.
The end of the istringstream stream occurs at the end of the string. E.g.
 
================================================
#include <iostream>
using namespace std;
 
void PrintBuffer(istream &s)
{
cout << s.rdbuf() << "--" << endl;
}
 
int main()
{
double x{17.5};
cout << "Enter Double" << endl;
string s;
cin >> s;
istringstream istr (s);
istr >> x;
cout << "You entered x = " << x << endl;
PrintBuffer(istr);
return 0;
}
================================================
 
 
Mike.
"Öö Tiib" <ootiib@hot.ee>: Nov 11 02:12PM -0800

On Thursday, 11 November 2021 at 13:42:29 UTC+2, Juha Nieminen wrote:
> seem to be such a strong instinct to write that line in order to get
> rid of the "std::" prefix? You see it all the time, and it just puzzles
> me where this tidbit of habit comes from and how people learn it.
 
It is so as Bjarne Stroustrup teached that with his examples from day he
added namespaces into C++ programming language .
Now Bjarne's coding guidelines suggest narrowing the usage of it somewhat ...
<http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rs-using>
... but no one apparently reads that.
 
Additionally there now are innumerable "competitive programming sites"
like TopCoder, CodeForces, CodeChef, CodeGolf where C++ participants
habitually start their works with two lines:
 
#include <bits/stdc++.h>
using namespace std;
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 01:59PM -0800

Hello,
 
 
More of my philosophy about the too much purism philosophy of Rust and more..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think i am smart, and i think that Rust compiler and language is too much "purist", it looks like the too much purism of Haskell functional programming language, since i say that Rust doesn't provide us with OOP inheritance, but it is too much restrictive, and it is the deficiency of Rust, since inheritance has advantages and disadvantages, so we have to balance well and provide also with inheritance so that to be efficient, so i think that C++ and C# are better than Rust in this regard, and here is the advantages and disadvantages of OOP inheritance, :
 
https://www.ianswer4u.com/2017/09/oops-inheritance-advantages.html
 
More of my philosophy about NP-hard problems and about Rust and C++..
 
I think i am smart and i have just quickly looked at Rust compiler and i think that since the Rust compiler has included race detection so
it is NP-hard, so that means that Rust compiler will never know in race detection which of races are real race conditions(Read here in the following paper so that to understand it: https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf), and, this is the reason why it is difficult to use a tool to find race conditions accurately, so then i think that C++ is still useful by using it with Threadsanatizer and Address sanatizer even if C++ is getting complex as i just said the following:
 
Also C++ has the following problem:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 01:27PM -0800

Hello,
 
 
 
More of my philosophy about NP-hard problems and about Rust and C++..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think i am smart and i have just quickly looked at Rust compiler and i think that since the Rust compiler has included race detection so
it is NP-hard, so that means that Rust compiler will never know in race detection which of races are real race conditions(Read here in the following paper so that to understand it: https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf), and, this is the reason why it is difficult to use a tool to find race conditions accurately, so then i think that C++ is still useful by using it with Threadsanatizer and Address sanatizer even if C++ is getting complex as i just said the following:
 
Also C++ has the following problem:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 01:00PM -0800

Hello,
 
 
More precision of my philosophy about safety-critical systems and C++ and Rust programming languages..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
Here is more proof that Rust has to be used in safety-critical systems:
 
"Safe Rust guarantees an absence of data races, which are defined as: two or more threads concurrently accessing a location of memory."
 
So i think that detecting races with the other ways than the one of Rust are NP-hard and they do report false alarm in that many of reporting race conditions are not real ones, so C++ has not to be
used in safety-critical systems.
 
And read my previous thoughts:
 
I think i am smart, and i will say that C++ has not to be used
in safety-critical systems, and we have to use Rust in safety-critical
systems because it is suited for safety-critical systems and
safety-critical systems are those systems whose failure could result in loss of life, significant property damage, or damage to the environment, here is why:
 
Difficulties in race Detection
 
"When using multiple semaphores in static race detection is NP-hard
[9], which means it is hard to find an efficient solution. If the
synchronization mechanism is weaker than semaphores, an exact
and efficient algorithm does exist [10]. Otherwise, only heuristic
algorithms are available [3, 5]. Because heuristic algorithms will
only report potential race conditions, which means there may be
false alarm in that many of reporting race conditions are not real
ones. However, since detecting race condition is NP-hard
problem, one will never know which of them are real race
conditions. And, this is the reason why it is difficult to use a tool
to find race conditions accurately."
 
Read more here on the following paper so that to notice it:
 
https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf
 
Also C++ has the following problems:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
• While being a strongly-typed language, C++ leaves too many holes to
circumvent the type system, deliberately or unintentionally.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
Thank you,
Amine Moulay Ramdane.
Amine Moulay Ramdane <aminer68@gmail.com>: Nov 11 12:48PM -0800

Hello,
 
 
More of my philosophy about safety-critical systems and C++ and Rust programming languages..
 
I am a white arab from Morocco, and i think i am smart since i have also
invented many scalable algorithms and algorithms..
 
I think i am smart, and i will say that C++ has not to be used
in safety-critical systems, and we have to use Rust in safety-critical
systems because it is suited for safety-critical systems and
safety-critical systems are those systems whose failure could result in loss of life, significant property damage, or damage to the environment, here is why:
 
Difficulties in Detection
 
"When using multiple semaphores in static detection is NP-hard
[9], which means it is hard to find an efficient solution. If the
synchronization mechanism is weaker than semaphores, an exact
and efficient algorithm does exist [10]. Otherwise, only heuristic
algorithms are available [3, 5]. Because heuristic algorithms will
only report potential race conditions, which means there may be
false alarm in that many of reporting race conditions are not real
ones. However, since detecting race condition is NP-hard
problem, one will never know which of them are real race
conditions. And, this is the reason why it is difficult to use a tool
to find race conditions accurately."
 
Read more here on the following paper so that to notice it:
 
https://www.sjsu.edu/people/robert.chun/courses/cs159/s3/Y.pdf
 
Also C++ has the following problems:
 
- C++ is a highly complex language. Learning and fully understanding C++
requires a huge learning effort. C++ code does not always do what one
would 'intuitively' expect from looking at the source code. At the
same time, the high complexity of C++ increases the probability of
compiler errors. C++ compiler writers are only humans, after all.
 
• While being a strongly-typed language, C++ leaves too many holes to
circumvent the type system, deliberately or unintentionally.
 
More of my philosophy about C++ and Rust and Microsoft and safety-critical systems..
 
I invite you to read the following from Microsoft about Rust programming language:
 
Microsoft: Rust Is the Industry's 'Best Chance' at Safe Systems Programming
 
https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/
 
I think that the above article is not correct, since i think that
Rust is suited for safety-critical systems, so i think Rust is better
than C++ in the safety-critical systems, but i think that C++ will
still be useful with the Address sanitizer and ThreadSanatizer,
and read my below thoughts since i have just added something in them:
 
More of my philosophy about memory safety and inheritance in programming languages..
 
"Address sanitization is not a security feature, nor does it provide memory-safety: it's a debugging tool. Programmers already have tools to detect that the code they've written has memory problems, such as use-after-free or memory leaks. Valgrind is probably the best-known example. This gcc feature provides (some of) the same functionality: the only new thing is that it's integrated with the compiler, so it's easier to use.
 
You wouldn't have this feature turned on in production: it's for debugging only. You compile your tests with this flag, and automatically they detect memory errors that are triggered by the test. If your tests aren't sufficient to trigger the problem, then you still have the problem, and it'll still cause the same security flaws in production.
 
Rust's ownership model prevents these defects by making programs that contain such defects invalid: the compiler will not compile them. You don't have to worry about your tests not triggering the problem, because if the code compiles, there cannot be a problem.
 
The two features are for different sets of problems. One feature of address sanitization is to detect memory leaks (allocating memory and neglecting to free it later). Rust makes it harder to write memory leaks than in C or C++, but it's still possible (if you have circular references). Rust's ownership model prevents data races in sequential and multi-threaded situations (see below). Address sanitization doesn't aim to detect either of those cases. But you can use ThreadSanatizer"
 
And using just plain C#, it has better memory protection, since the GC and runtime make it impossible to leak, double-free, or access out-of-bounds. C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#.
 
I think that a programming language has to provide "inheritance",
and the new Rust programming language doesn't provide it and i think that it is a deficiency in Rust, here is why:
 
As a software developer you have to become more efficient and productive. So you need to make sure the code you write is easily reusable and maintainable. And, among other things, this is what inheritance gives you - the ability to reuse without reinventing the wheel, as well as the ability to easily maintain your base object without having to perform maintenance on all similar objects.
 
 
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.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)