4 ms·

You're gonna need a citation (preferably, an example) for the performance claim. As for this comment of yours: > I can't imagine a single reason to tell peopl

You're gonna need a citation (preferably, an example) for the performance claim. As for this comment of yours: > I can't imagine a single reason to tell people not to use const instance fields. That's weird, did you not read the blog post? It literally gave you a reason not to, you don't need to imagine anything. If you don't think it's a compelling reason then that's another story, but it's a valid reason.

keldaris 10y ago
It's impossible to provide general benchmarks, since the impact will be completely case specific. However, the reason I didn't provide a citation is because the OP already gives an example - blink::serializedCharacterData gets moved over the read-only data segment if you add const, with obvious consequences for, say, thread-local accesses in tight loops. In my own code, I've seen adding a const modifier result in 20-60% perf improvement in fairly extreme cases. In other cases (probably most cases), it won't change much. More importantly, I've never seen an example where adding const would ever decrease CPU performance by any amount at all (other than compiler bugs, which can ruin any language feature). Accordingly, my personal recommendation is that everything that can be const should be. It's an easy thing to do that may help and definitely won't hurt. > That's weird, did you not read the blog post? It literally gave you a reason not to, you don't need to imagine anything. If you don't think it's a compelling reason then that's another story, but it's a valid reason. That's an outright compiler bug, not a general language reason. Obviously, it's a valid caveat if you're using that specific compiler and care about that edge case, but it's hardly a general argument.
- wfunction 10y ago
  > However, the reason I didn't provide a citation is because the OP already gives an example - blink::serializedCharacterData gets moved over the read-only data segment if you add const, with obvious consequences for, say, thread-local accesses in tight loops. Uh, that wasn't an instance field, was it? https://codereview.chromium.org/2608823002/diff/20001/third_party/WebKit/Source/platform/text/CharacterPropertyDataGenerator.cpp https://codereview.chromium.org/2608823002/diff/20001/third_... > That's an outright compiler bug, not a general language reason. It's not a bug, just a missed performance optimization. The code behaves correctly. And I was merely responding to your comment, "I can't imagine a single reason to tell people not to use const instance fields." The underlying language reason I have for it is not something you may agree with, but it's that it Seems Wrong (TM) to me for the fields of a class to dictate how the class's instances can be constructed or assigned to. Again, I don't claim I can convince you here. It just seems like poor design to me, and it's given me trouble so many times without once actually providing me a benefit. So it's a reason. YMMV.
  - keldaris 10y ago
    > Uh, that wasn't an instance field, was it? https://codereview.chromium.org/2608823002/diff/20001/third_.. https://codereview.chromium.org/2608823002/diff/20001/third_.... Fair point, I was indeed being insufficiently precise. That code is a typical example of how const helps performance, concrete performance gains from applying const to instance fields in particular are much rarer in practice. > It's not a bug, just a missed performance optimization. The code behaves correctly. I think the MSVC devs classify it as a codegen bug since the cause is a logic error in the optimizer. The code does behave correctly, but it's reasonable to expect that optimization to happen, and it does in GCC / clang. My point here is simply that in this case MSVC is the outlier, therefore the example does not constitute a general argument against using const in this context. > The underlying language reason I have for it is not something you may agree with, but it's that it Seems Wrong (TM) to me for the fields of a class to dictate how the class's instances can be constructed or assigned to. I happen to have the opposite preference, namely that if you have constant data in a struct, it makes sense to say so at the declaration site for clarity. Regardless, it's a perfectly reasonable stylistic preference. I only argued against it because the phrase "NEVER have const instance fields. Ever." seems much too strong for what's ultimately a subjective choice. In doing so, however, I may have erred in the opposite direction and made overly strong statements myself. Mea culpa. > It just seems like poor design to me, and it's given me trouble so many times without once actually providing me a benefit. So it's a reason. YMMV. It's definitely a valid personal preference. When you say using const has given you trouble many times, do you have any particularly poignant example in mind?
    - wfunction 10y ago
      > Fair point, I was indeed being insufficiently precise. That code is a typical example of how const helps performance OK, well, I was merely saying you need a citation for the situation we were discussing. I still stand by it. > I think the MSVC devs classify it as a codegen bug since the cause is a logic error in the optimizer. I'm gonna pull your own type of argument here, which is that they only consider it a bug because they have their own stricter guidelines for what they expect, not because it's actually a general language implementation bug. Definitely not something I'd call an "outright compiler bug" when the code is behaving sanely. > When you say using const has given you trouble many times, do you have any particularly poignant example in mind? I don't have a particularly poignant one at the top of my head right now, but I can give you a hypothetical one to illustrate the idea. Look at std::binary_negate (for our purposes assume the functor is required to be const-callable). People put const on the instance field of that sort of thing because, well, everything that can be const should be const dammit! Except now it gives you hell trying to assign to the object. That's the issue.
Arnt 10y ago
You can overload on const in C++, so int a(foo b) and int a(const foo b) can coexist. We used this in Qt 2.0, there were a few cases where we could get significantly more oomph if we knew the argument was const. Ff a function takes a struct (or class) as argument can calls otherfunction(foo.bar), then the constness of foo's bar field matters. The same might apply to fields of this.
- wfunction 10y ago
  Nobody said it doesn't "matter" whether you put const. I was saying it's not worthwhile.
- pontobart 10y ago
  You cannot overload on the const. If you try to define both int a(int b) and int a(const int b) the compiler will complain about a redefinition. You can declare the function using int a(int b) in the header and then define it via int a(const int b).

keldaris 10y ago

It's impossible to provide general benchmarks, since the impact will be completely case specific. However, the reason I didn't provide a citation is because the OP already gives an example - blink::serializedCharacterData gets moved over the read-only data segment if you add const, with obvious consequences for, say, thread-local accesses in tight loops. In my own code, I've seen adding a const modifier result in 20-60% perf improvement in fairly extreme cases. In other cases (probably most cases), it won't change much. More importantly, I've never seen an example where adding const would ever decrease CPU performance by any amount at all (other than compiler bugs, which can ruin any language feature). Accordingly, my personal recommendation is that everything that can be const should be. It's an easy thing to do that may help and definitely won't hurt. > That's weird, did you not read the blog post? It literally gave you a reason not to, you don't need to imagine anything. If you don't think it's a compelling reason then that's another story, but it's a valid reason. That's an outright compiler bug, not a general language reason. Obviously, it's a valid caveat if you're using that specific compiler and care about that edge case, but it's hardly a general argument.

wfunction 10y ago
> However, the reason I didn't provide a citation is because the OP already gives an example - blink::serializedCharacterData gets moved over the read-only data segment if you add const, with obvious consequences for, say, thread-local accesses in tight loops. Uh, that wasn't an instance field, was it? https://codereview.chromium.org/2608823002/diff/20001/third_party/WebKit/Source/platform/text/CharacterPropertyDataGenerator.cpp https://codereview.chromium.org/2608823002/diff/20001/third_... > That's an outright compiler bug, not a general language reason. It's not a bug, just a missed performance optimization. The code behaves correctly. And I was merely responding to your comment, "I can't imagine a single reason to tell people not to use const instance fields." The underlying language reason I have for it is not something you may agree with, but it's that it Seems Wrong (TM) to me for the fields of a class to dictate how the class's instances can be constructed or assigned to. Again, I don't claim I can convince you here. It just seems like poor design to me, and it's given me trouble so many times without once actually providing me a benefit. So it's a reason. YMMV.
- keldaris 10y ago
  > Uh, that wasn't an instance field, was it? https://codereview.chromium.org/2608823002/diff/20001/third_.. https://codereview.chromium.org/2608823002/diff/20001/third_.... Fair point, I was indeed being insufficiently precise. That code is a typical example of how const helps performance, concrete performance gains from applying const to instance fields in particular are much rarer in practice. > It's not a bug, just a missed performance optimization. The code behaves correctly. I think the MSVC devs classify it as a codegen bug since the cause is a logic error in the optimizer. The code does behave correctly, but it's reasonable to expect that optimization to happen, and it does in GCC / clang. My point here is simply that in this case MSVC is the outlier, therefore the example does not constitute a general argument against using const in this context. > The underlying language reason I have for it is not something you may agree with, but it's that it Seems Wrong (TM) to me for the fields of a class to dictate how the class's instances can be constructed or assigned to. I happen to have the opposite preference, namely that if you have constant data in a struct, it makes sense to say so at the declaration site for clarity. Regardless, it's a perfectly reasonable stylistic preference. I only argued against it because the phrase "NEVER have const instance fields. Ever." seems much too strong for what's ultimately a subjective choice. In doing so, however, I may have erred in the opposite direction and made overly strong statements myself. Mea culpa. > It just seems like poor design to me, and it's given me trouble so many times without once actually providing me a benefit. So it's a reason. YMMV. It's definitely a valid personal preference. When you say using const has given you trouble many times, do you have any particularly poignant example in mind?
  - wfunction 10y ago
    > Fair point, I was indeed being insufficiently precise. That code is a typical example of how const helps performance OK, well, I was merely saying you need a citation for the situation we were discussing. I still stand by it. > I think the MSVC devs classify it as a codegen bug since the cause is a logic error in the optimizer. I'm gonna pull your own type of argument here, which is that they only consider it a bug because they have their own stricter guidelines for what they expect, not because it's actually a general language implementation bug. Definitely not something I'd call an "outright compiler bug" when the code is behaving sanely. > When you say using const has given you trouble many times, do you have any particularly poignant example in mind? I don't have a particularly poignant one at the top of my head right now, but I can give you a hypothetical one to illustrate the idea. Look at std::binary_negate (for our purposes assume the functor is required to be const-callable). People put const on the instance field of that sort of thing because, well, everything that can be const should be const dammit! Except now it gives you hell trying to assign to the object. That's the issue.

Arnt 10y ago

You can overload on const in C++, so int a(foo b) and int a(const foo b) can coexist. We used this in Qt 2.0, there were a few cases where we could get significantly more oomph if we knew the argument was const. Ff a function takes a struct (or class) as argument can calls otherfunction(foo.bar), then the constness of foo's bar field matters. The same might apply to fields of this.

wfunction 10y ago
Nobody said it doesn't "matter" whether you put const. I was saying it's not worthwhile.
pontobart 10y ago
You cannot overload on the const. If you try to define both int a(int b) and int a(const int b) the compiler will complain about a redefinition. You can declare the function using int a(int b) in the header and then define it via int a(const int b).