   [C++]const or non const for function parameters?
  Which is better?This?class X{int i;public:void set(int val) { i = val; }};or this?class X{int i;public:void set(const int val) { i = val; }};In the second example, the temporary variable val is constant which means that the compiler may optimize it by placing it in ROM memory, thus access to it is faster, which means the theoretically, the 2nd is faster.   
Quote:In the second example, the temporary variable val is constant which means that the compiler may optimize it by placing it in ROM memory, thus access to it is faster, which means the theoretically, the 2nd is faster.This is outmoded information; a compiler rarely (if ever) makes optimization decisions based on const. const does not mean 'cannot change,' it means, 'cannot change in this context or via this access point' and the compiler has that information already, regardless of whether or not you put const on it.Also, the compiler cannot really put function parameters in read-only memory (read-only memory is read-only, function parameters generally change).Your two examples are the same, performance-wise. The only difference is functional: the compiler will allow you to mutate val in the first example, and the will emit a warning in the second. That is all. This largely boils down to style.I never write the second example (pass-by-value as const).   ;  For pass-by-value, const is useless. The second example is just trouble with no benefits.If I saw the second example in code I had to work with, I'd assume the author doesn't quite understand const yet and send them here.   ;  I had no idea. Live and learn. :|   ;  Personally I'd rather see people on my team use the second example. If you expect a variable not to change value within this function then tell me that. It doesn't always have to be about optimisation.Sure, with such a basic function above, it seems rather pointless, but at least it's obvious. If you have a team of 30 odd programmers pushing out a build quickly when approaching an important deadline it's important to make code obvious and give you errors/warnings if you use it wrong.Yes, it can also be a pain to change the const nature of the variable if the situation requires it, but at least you'll know to look out for any potential issues with doing so as you have been warned already.   ;Quote:Original post by HodgmanFor pass-by-value, const is useless. The second example is just trouble with no benefits.But isn't there the benefit of you being unable to accidentally do this:void set(const int val){  ++val; // Accidentally change val, prevented by const  i = val;};Quote:Original post by Westie007If you expect a variable not to change value within this function then tell me that.Why would the client ever care about that?   ;Quote:Personally I'd rather see people on my team use the second example. If you expect a variable not to change value within this function then tell me that. It doesn't always have to be about optimisation.With this prototype: T f(int x), the only people who will not know that the value they pass for x will not change are people who don't know enough C++. The solution is to educate them, not dumb down your code to cater to them.Quote:But isn't there the benefit of you being unable to accidentally do this:The example you've provided rarely happens in practice, like that, and examples like that are another hallmark of a inept programmer. You can never protect yourself from inept programmers. But I realize you're providing a very academic example.However, the idea you're after does sometimes happen in practice, via programmers with poor code-clarity sense trying to reuse by-value parameters as locals. In this case the const could be considered a benefit, technically, but I also feel it falls under a similar scenario are the situation I described above: people who reuse by-value parameters as local temporaries are generally proliferating poor programming habits. It makes the code less clear, in most cases. I'd rather retrain those people than cruft up my code with unnecessary verbosity, but I will admit that that verbosity lets one catch those people more easily. However, I prefer to either avoid hiring people who would write such code, or (since the operation is rarely dangerous) simply catching it in their code reviews.   ;Quote:Original post by DevFredQuote:Original post by Westie007If you expect a variable not to change value within this function then tell me that.Why would the client ever care about that?The client might not care, but the other programmers on my team might, also the programmer who could inherit the code base once I've left the project.;Quote:The client might not care, but the other programmers on my team might, also the programmer who could inherit the code base once I've left the project.Anything passed by-value won't change from perspective of the caller, const or no. Anything using referential passing semantics might, and in that case a const may be appropriate. But that's not the situation we're talking about; we're talking about by-value passing of (specifically) built-in types like int.   