Const helps optimisations since the compiler knows in advance that the value won't change. (The compiler can analyse its use but with a load of inline methods and references being recursively thrown around it might not always be feasible to detect it.)
Const helps correctness since you are more clearly stating your intentions to yourself.
Const references in inline or inlinable functions are handy because it gives the compiler the option to copy-construct, which may or may not be more efficient.
Personally, I almost always use either const references or non-const pointers for input and output arguments respectively. Sure some of those const references are interchanable with copy-constructed objects, especially for builtins, but I say having ANY consistent style is better than NO consistent style(*), whichever style you choose.
(*) Apart from dumb, crappy styles (MS "Hungarian" I'm looking at you) and the inevitable exceptional circumstance.
Semantically, should "setters" in C++ use constant parameters, even for built-ins?
In your situation, don't use const. Pass by value. It doesn't matter, because even if you change the value of the parameter variable, the outside variable(the one passed to the function won't change).
Use const only with references.
1.
2.
The difference here is that in 1, you can pass constant values as well.
y(10); // OK in 1, error in 2
Use const only with references.
1.
void y(const int &x){}2.
void y(int &x){}The difference here is that in 1, you can pass constant values as well.
y(10); // OK in 1, error in 2
Quote:The difference here is that in 1, you can pass constant values as well.
Or in a more general way, you can't pass a temporary as a non-const reference...
Quote:Original post by sheep19
The difference here is that in 1, you can pass constant values as well.]
Isn't it the same? :)
I always pass int by non-const value because the semantics are simple and understood.
spraff is right, too, but I'm too lazy to write the extra stuff without achieving anything practical.
This one totally boils down to personal preference.
spraff is right, too, but I'm too lazy to write the extra stuff without achieving anything practical.
This one totally boils down to personal preference.
Quote:JSF AV C++ CODING STANDARDS
AV Rule 116
Small, concrete-type arguments (two or three words in size) should be passed by value if changes made to formal parameters should not be reflected in the calling function.
Rationale: Pass-by-value is the simplest, safest method for small objects of concrete type. Note that non-concrete objects must be passed by pointer or reference to realize polymorphic behavior. See rules AV Rule 117 and AV Rule 118.
I don't think the topic here is about whether to pass by value or by reference. I think the topic is, when you pass by value, is there advantages to make it const in function definition.
For someone reading the declaration does not care about if there is const or not, becouse it doesn't make any difference. So its better to left out.
For someone reading the definition it might make things more clear. If there is a lot of stuff going on, I'd argue it's quicker and easier to analyze the function. Working memory has a capacity of around four to seven chunks simultaneously. Making stuff const that does not change, does simplify the function.
Edit: Umm, guess I didn't read the topic so well after all. For setters, which are one line functions, const only adds clutter. But for more complex functions I think there are benefits for const.
// .hvoid dostuff(int x);// .cppvoid dostuff(int const x){ // do stuff}For someone reading the declaration does not care about if there is const or not, becouse it doesn't make any difference. So its better to left out.
For someone reading the definition it might make things more clear. If there is a lot of stuff going on, I'd argue it's quicker and easier to analyze the function. Working memory has a capacity of around four to seven chunks simultaneously. Making stuff const that does not change, does simplify the function.
Edit: Umm, guess I didn't read the topic so well after all. For setters, which are one line functions, const only adds clutter. But for more complex functions I think there are benefits for const.
I usually make all in-parameters const, even if passed by value.
Reasons:
- helps prevent goofy rhs = lhs type mistakes
- could feasibly improve optimizations on inline methods
I suppose it's a bit more typing, but that's hardly noticeable compared to my somewhat verbose class and variable names.
As others have said before, const in an argument list is part of the contract between the caller and the callee - at least when applied to references and pointers. When applied to a value, it's merely a minutia of the internal implementation of the callee, which is of absolutely no concern to the caller and only serves to clutter up the contract.
Author
Quote:Original post by Red Ant
As others have said before, const in an argument list is part of the contract between the caller and the callee - at least when applied to references and pointers. When applied to a value, it's merely a minutia of the internal implementation of the callee, which is of absolutely no concern to the caller and only serves to clutter up the contract.
Are you saying:
1. Variables that will never change should always be const unless they are in the parameter list of a function, or
2. Variables that will never change should always be const, and if they are in the parameter list of a function, they should be made references so as not to confuse whomever is calling the function?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
