Good Morning, 

I just have a quick question about good programming practice with parameter arguments in C++. 

Is it good programming practice to const all parameter arguments that will not be changed internally? For example. 

void Agent::setHealth( const int h ){
	health = h;
}

However, if I have the same function, but this time wish to signify to users that the parameter value might not be what's assigned to a private/protected variable inside the class I could do something like this

void Agent::setHealth( int h ){
	health = glm::clamp( h , 0 , INT_MAX );
}

I am also talking about primitive types available through C++ not const referenced variables passed as arguments. 

Is it a waste of time to 'const' and just use the variable with function documentation?

Thanks so much for the time,

Mike

Maybe I am misunderstanding your question, but in your seconds example, the parameter can still be const (when I looked up glm::clamp, I see that the first parameter is const reference). I feel that it is not very important to use const in your case here. It can be used to indicate to the programmer that this variable will not change later in this function. But when the person reads the whole function, it is already clear to her whether this actually changes or not. What is more important in my opinion, is to use const-correctness wherever you can for classes (class member functions) and objects. Because they can potentially modify their own state, not using const will make your code very hard to reason about for example when considering multithreading. In your case here, not so much, but it can maybe improve readability for long functions.

In the case you give it makes no difference to the people using the class.

A const reference or a pointer to a const object mean you won't be modifying the thing they pass.  A non-const reference or a pointer to a non-const object generally means the object will be modified. 

Integer values passed to a function cannot be modified, the objects are passed by value so there is no point in marking them const.  It doesn't matter what you do inside the function with the int, the parameter will never be used elsewhere.

In your example the only thing I can think of that it "might" effect is compiler optimization of code, especially if the function is inlined. However I'm guessing that a modern compiler is going to be able to optimize it anyway so it likely won't make a difference. 

I think you guys are right. It really does not add any value to const a primitive parameter variable for the sake of documentation to whomever the user might be. 

I have never seen it done that way but was just wondering if it might be good practice since I have very limited exposure to production level code. 

Thanks again,

Mike

15 hours ago, too_many_stars said:

I think you guys are right. It really does not add any value to const a primitive parameter variable for the sake of documentation to whomever the user might be.

constness of pointed data or references is important for the caller as it expresses promises to what you give to the method.

"const int" would seem like an implementation detail inside the function to me, which should not be in the API.

Externally supplied values could be internally be modified (replace special values like "use -1 for default"), or internal conversion to a different unit could be performed (you specify seconds, internal code works in micro seconds). Such conversions are not part of the API, and should thus not affect it.

The only reason to use const int as a parameter would be as an instruction to the function implementer that this value shouldn't be changed.

So basically, use it if it helps. If you are writing some function/method and you really don't want that parameter to change, go ahead and mark it const... it will make zero difference to anyone using the function. As @Alberth said, it's not really relevant to the class API, but equally, it won't do any harm either. The only potential downside would be forcing a recompilation of clients when you change the header.