On Wed, Jul 27, 2016 at 12:06:51PM +0100, Guillaume Munch wrote: > Hi Scott, > > > - f(…, bool b) > + f(…, bool const b) > > This being passed by value, this changes nothing for the declaration. > The two signatures are even considered equal for overloading (if it > came to this). So I recommend leaving the header unchanged.
Good to know. I often switch back and forth between the .cpp and .h files to understand a group of functions. Sometimes I would read the signature of the declaration in the .h file and then go directly to the function body without looking at the signature of it. But now I realize this is a bad idea because the two signatures are not necessarily the same. const can be different and even the parameter names are not required to be the same, so now I know that when I go to the implementation, I should not skip over the implementation's signature. > For the function definition, the difference is in terms of > documentation. If you are adding const in the definition because you > find it clearer this way, then it is a good reason to change it. Yes this was my intention. To me it has the same purpose as declaring a local variable const in the body of a function. For example, if I see that "param" is used at the end of a function I know that "param" is a const parameter, I don't have to read the whole function looking to see if param was modified in the middle. In addition to readability, I think it can in some (unlikely) situations prevent future coding mistakes. e.g. I might write the code and at the end of the body I use "param" making the assumption that it has the same value that it started with. If someone (e.g. future me) comes along and changes the value in the middle of the function they'll get a compiler error and think twice before removing const. I think the benefits are especially useful for long functions. Do you also const parameters and const local variables useful for understanding and future-proofing functions or not really? If no, do you find them annoying or just don't care? > In this case, you can see "const" as a detail of implementation that the > user of the header does not care about. If you see it that way, then the > difference between the declaration and the definition looks strange no > longer. I see, makes sense now. > The answer would be different if the const was somewhere inside, e.g.: > - f(…, bool & b) > + f(…, bool const & b) > in which case the conveyed meaning is entirely different, and it would > be a matter of priority to correctly document the declaration. Indeed, I do see the difference. So to double-check, no one is against the .cpp change I proposed, right? (I will not commit the .h change after this helpful conversation) Thanks for this detailed explanation, Guillaume. I think that small things like this help me build up a better understanding of C++. Scott
signature.asc
Description: PGP signature
