Re: Code guidelines

On 04/09/2024 03:45, David Brown wrote:

On 03/09/2024 18:37, Thiago Adams wrote:
 

>
I also have a interesting sample with linked list
>

 Speaking generally rather than specifically about this code, your extra checks are redundant when the code is run from a single thread, and insufficient if it is later used from multiple threads (accessing the same data).  But extra checks can fool people into thinking it is safe - since the checks are unnecessary for sequential code they must have been put there to catch rare race conditions.
  There are times when you want seat-belts /and/ airbags.  But focusing on that instead of making sure the driver is competent is not helpful!
  

In Cake (my front-end), I made `assert` a special built-in function to allow it to be used by static analysis.
For instance:
`assert(p != 0);`
Static analysis will then assume that `p` is not zero after this line.
However, this raises a question:
Does assert overrides what the compiler already knows?
For example:
int i = 1;
assert(i == 2);
Here, the compiler knows `i` is `1`, but the `assert` (i.e., the programmer) is claiming that it’s `2`!
I then reconsidered my view. `Assert` is about what the programmer is stating to be true. (Programmer can be wrong) It is not a "override command".
I think this is applicable for any "assume concept".
C++ 23 added [[assume( expression )]]
"Tells the compiler to assume that an expression will always evaluate to true at a given point ..." "The purpose of an assumption is to allow compiler optimizations based on the information given"
There is a big warning there :
"IMPORTANT: DANGEROUS OPERATION, USE WITH CARE"
https://en.cppreference.com/w/cpp/language/attributes/assume
I also may add this [[assume]] to cake, but assert also gives me a runtime check.
In the first example `assert(p != 0)`, the compiler knows that `p` is MAYBE `null`. But the programmer is asserting that `p` cannot be `null`, so the compiler will follow the programmer's assertion.
Perhaps the programmer knows something the compiler doesn’t?
This is similar to a case with a linked list, where the programmer knew that if the `head` is `null`, then the `tail` must also be `null`.
However, if the compiler is certain about a fact and encounters an `assert` with conflicting information, it should trigger a warning.
For example:
int i = 0;
assert(i != 0); // Warning
When the compiler finds an assert, that is not adding extra information but only saying what the compiler already knows, then we don't have warnings. But, this is a redundant check.
int i = 0;
assert(i == 0); // ok
On the other hand, redundant 'if' I have a warning.
if (i == 0) {} //warning 'i' is always 0 here!
So, basically.
- if assert has a conflicting information compared with what compiler already knows, then it is a warning. Compiler will not override what it knows?
- If the assert gives the exactly information compiler already have, then is is not a warning. Both compiler and programmers knows the same thing.
- If the compiler is not sure about a fact and the programmer gives a plausible fact then the compiler will assume the programmer is correct.