-
-
Notifications
You must be signed in to change notification settings - Fork 885
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify that marking certain member variables const can hinder performance #147
Comments
class MyClass private: hey @andreastedile look at the code, here the attribute m_value is initialized with 0 and it was being expecting that in the future the value will be same (variable is not expected to change after the initialization). so, if by mistakely you try to assign with any other value it will not happen if and only if we declare it as const then your mistake will not cause any future problem. |
@mallikpramod You have misunderstood this post. I am suggesting that the part discussing const correctness of an object field should be updated to clarify that, if an object is expected to be moved, then its fields must not be marked const if they are containers. A field being const would prevent the whole object from being moved (thus inducing a copy), hindering performance. I am not asking for a clarification of what const correctness is. |
@andreastedile Well, thanks! |
In the 03-Style document, I read the following sentence:
However, we know that if, for example, we mark a container as
const
, we prevent it from being moved, possibly hindering performance. Marking fields asconst
is useful to enforce invariants; however, it "interferes" with performance. If both const correctness and performance are important, one could leave the field non-const, make it private and define a field getter.The text was updated successfully, but these errors were encountered: