Aliasing is no joke and currently the only reason why some arithmetic intensive code-bases still prefer Fortran even nowadays.
While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is a pain to do it properly.
While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is a pain to do it properly.
Decades ago I was a Fortran developer and encountered a very odd bug in which the wrong values were being calculated. After a lot of investigation I tracked it down to a subroutine call in which a hard-coded zero was being passed as an argument. It turned out that in the body of that subroutine the value 4 was being assigned to that parameter for some reason. The side effect was that the value of zero because 4 for the rest of the program execution because Fortran aliases all parameters since it passes by descriptor (or at least DEC FORTRAN IV did so on RSX/11). As you can imagine, hilarity ensued.
"Passing constants to a subprogram" https://www.ibiblio.org/pub/languages/fortran/ch1-8.html
Yes. That is the main solution and it is not a good one.
1- `restrict` need to be used carefully. Putting it everywhere in large codebase can lead to pretty tricky bugs if aliasing does occurs under the hood.
1- Restrict is not an official keyword in C++. C++ always has refused to standardize it because it plays terribly with almost any object model.
For C++, yes, I agree.