131–140 of 197 posts
He only talks about const args, where the compiler does not try yet to check for casts which violate the constness guarantees. (DFA, Escape Analysis). And thus misses all important optimizations. You cannot rely on that never being implemented in the future. With LTO they already do I think.
The most succinct way I've heard this explained is: "Const means ' I won't mutate this'. It doesn't mean ' nobody will mutate this'." To do optimizations, compilers really need to know that nobody will mutate a value; just knowing that a particular function won't mutate a value isn't that helpful.
True to form, there's multiple forms of const in C++. const on a methond says "I won't mutate the state of this class (except for members explicitly marked as mutable) A const reference says I won't mutate this (unless I const_cast away the constness first) But a const variable actually is a promise to C++, saying "This object will never mutate after initialization ever forever I promise for real this time " ( except…
I've worked with JavaScript weenies who are in love with the const declaration. They don't have an answer, though, when I ask, "Shouldn't the compiler be able to notice that a variable isn't changed in it's lifetime?" Most of the const values are just local and never leave the function but the weenies continue to stomp their feet when I use "var". The compilers are smart. Let them do their thing.
const doesn't actually stop data from changing, just reassignment. const user = {id: 1, status: 'active'}; user.status = 'disabled'; is valid javascript
final int[] arr = {1, 2, 3};
arr[1] = 10;
Earlier quoted context omitted.
>The author didn't ask me about it, he just assumed the compiler was buggy and gave us a bad review. Sigh. Did you write a letter complaining? Any response? Do you have a link to the review or copy of it? (Sorry, I just find this history fascinating).
I did complain to the author, but the damage was done. Can't undo a magazine article. I didn't save a copy of the magazine I was so annoyed. BTW, it goes on. A couple years ago a kind soul gently suggested I implement DFA since clang had invented DFA. (No, I didn't invent DFA either, but I do believe that Datalight Optimum C was the first DFA compiler for DOS.) http://www.program-transformation.org/Transform/CCompile…
Earlier quoted context omitted.
Does it enforce these attributes or are they just a promise by the code author?
D has a `pure` attribute for functions, and yes it is enforced. It's enforced even to the point where it becomes a PITA, but when you manage to make functions pure, you know it's solid. One pain point with pure functions is you can't insert debug logging statements. D has a special case for that - purity for a statement isn't checked if it is prefixed with the `debug` keyword: pure int square(int x) { debug printf("c…
Earlier quoted context omitted.
I'm not sure what you mean? Allocators are often pure in D, they probably shouldn't be but that would mean allocating outside the function which would be ugly and probably buggy too
Obviously a pure function can allocate memory on the stack. I would think it could also allocate memory on the heap, iff it was guaranteed that the memory was freed before the function exits. Was thinking that would be something the compiler would do. Forgive me I'm just a small brained firmware programmer.
Earlier quoted context omitted.
Does it enforce these attributes or are they just a promise by the code author?
D has a `pure` attribute for functions, and yes it is enforced. It's enforced even to the point where it becomes a PITA, but when you manage to make functions pure, you know it's solid. One pain point with pure functions is you can't insert debug logging statements. D has a special case for that - purity for a statement isn't checked if it is prefixed with the `debug` keyword: pure int square(int x) { debug printf("c…
Earlier quoted context omitted.
Does it enforce these attributes or are they just a promise by the code author?
They are a promise and that is precisely what makes them powerful. It gives GCC info it might not be able to derive, but you know to be true. You can even promise a func is pure without even implementing it in the same translation unit! That produces lots of improvement. See these two godbolt links: https://godbolt.org/z/v2zqJI https://godbolt.org/z/kk3Q3T
Actually that's the main point, as if it's in the same TU, the compiler can probably figure out a function is pure.