Ritchie notes the difficulty with optimization and aliasing and as far as I know the only portable C89/99 convention for this is using the appropriate function if what you want to do is memcpy() or memmove().
I love C and programming is mostly a hobby for me. But my language experience does not really extend beyond C and C++, other than reading about D, Lisp, Rust, etc. I also think the STL is the beautiful thing C++ gave us, and having it as a library is better than building these structures into the language. The STL relies heavily on iterators of course.
My question to HN is: do any languages that really emphasize pointers and iterators over arrays and indices have a non-cumbersome way of telling the compiler when no aliasing is expected? As a hobbyist, I am more interested in something like slices from D or parameter type restrictions than trivially obvious global guarantees like ``if you mutably borrow it then there is no aliasing''. Do D programmers find the slices helpful and easy? Is the syntax and/or semantics such that the programmer can provide the compiler with aliasing info? Are there a small number of type concepts for this or does it explode with the number of different data structures.
I know there is the restrict keyword, but I have always been too lazy to use it in C and even in C++ it seems (quadratically?) unlikely you would be energetic enough to properly declare which pairs of entities could not alias.
You see an example here
https://gcc.gnu.org/onlinedocs/gnat_ugn/Aliased-Variables-an...
To use C vocabulary, Ada always assumes restrict unless you make use of aliased, and it is a compile error to handle it otherwise.
Rust has this concept baked into the language: any mutable reference is statically guaranteed to not alias anything else that is accessible. Non-mutable references can alias each other, but I don't think there are any optimizations that could be inhibited by this.
I'm interested in any language innovations that have a smooth, suave feature for this. Rust changes the default, but in some sense its not an absolute improvement; where C bluntly assumes memmove(), Rust bluntly applies memcpy().
memmove versus memcpy only solves the problem for block moves, not for other array operations. Think about a Fast Fourier Transform or whatever where the compiler has to suspect that the inputs overlap in dumb ways.
It did not. STL was given to us by HP and SGI, and then C++ adopted STL into its standard library.
What HP and SGI did was to provide the first C++ working implementations of it, outside the ANSI C++ working group work.
For example I always assumed C came from a strong typing background and its premises was always about being portable. Neither of them are true.
C is notoriously weakly typed. There are lots of implicit casts that will automatically be applied. And (void *) is your door to freedom from types (this can be a good thing in some cases, of course.)
Yet it took up all these years until clang for anyone to start taking static analysis seriously in C, and even now many still ignore it.
In some circles maybe, but some industries have decades of experience applying static analysers to their C code, and companies have been selling static analysers throughout.
Therefore, just like with assembly, there is nothing too "unfortunate" about the language's design (including its "treatment of arrays"), and the fact that C has been, and still remains, highly popular is just the result of healthy competition, IMO.
There are a few little things that I wish were different (for example, I see the arrow symbol '->' as noisy and unnecessary - the simple period '.' would work with pointers just as well; also, the "semicolon cancer"...), but the language seems to be pretty usable the way it is.
