2 ms·

> 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

> 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.

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.