Making a char function parameter const?

Consider this function declaration:

int IndexOf(const char *, char);

where char * is a string and开发者_开发技巧 char the character to find within the string (returns -1 if the char is not found, otherwise its position). Does it make sense to make the char also const? I always try to use const on pointer parameters but when something is called by value, I normally leave the const away.

What are your thoughts?

Assuming you don't intend to adjust the value of either parameter:

I would have the function definition as:

int IndexOf( const char * const , const char )
{
    //...
}

But keep the function declaration as:

int IndexOf( const char * , char );

In other words:
I'd reveal the bare minimum level of const in the header, but then use the maximum possible level of const in the implimentation.

Why?

1. Seperating the header and implimentation allows me to change the parameters that are const in the implimentation without ever touching the header (except those that are vitally const, which should require a header change).
2. It's makes the code more self-documenting.
3. It makes it harder to introduce bugs without the compiler catching them as errors.
4. It makes it harder for other programmers to introduce bugs when making future changes.

Making a pass-by-value paramter const or not has "no effect" in terms of affecting the caller of the function - which is why you should keep them out the header - but they can make your implimentation more robust and easier to maintain.

Obviously, if it's more useful to change the parameter rather than copying it into another local variable then don't make it const for the sake of doing so.

Contrary to my co-answerers, I'd make the char const. After all, you don't want to change the character you're looking for in mid-search, do you? And since doing so inadvertently has a good chance of messing up your algorithm, const helps to make your code robust and easy to maintain.

It doesn't make sense because the caller won't be affected if you modify the second parameter's value.

Further, if you need to modify this argument inside the function it may help you save a few bytes on the stack rather than having to declare a separate local variable.

The below code is a good example of modifying an argument instead of having a local variable:

void foo (int count) {
  while (count--) {
    do_something();
  }
}

However, if your function is longer and you don't intend to modify its arguments, it may be rewarding in terms of maintenance to mark the corresponding arguments as const, but only in its definition, not in the declaration that resides in a header file. If you later decide that an argument shouldn't be const, you only have to change it in the definition.

For the example you gave the answers make sense, but in the more general case of passing by value there can be some instances where const might be helpful.

Generally this might be for non POD types where potentially even passing by value doesn't guarantee no visible side effects from changes. Furthermore if you absolutely know that your implementation won't be wanting to change it marking it const can help the compiler find bugs if/when someone accidentally changes the value later.

I tend to live by the rule "mark it const unless there's a reason for it to not be const"

I don't think it is necessary, as the char's value will be copied and any change to it won't be reflected outside of its scope.

It doesn't matter, so long as you are consistent.

As you can see, this question is a religious one. People come down on either side, and tend to fervently disagree with the opposing side.

Arguments can be made for or against either side. The arguments that are made can be contradicted.

For example, the arguments in the "make it const" camp tend to argue that it makes the code more self-documenting for maintenance programmers working on that function. This may well be true, and you might decide this is a good enough reason to mark your by-value parameters as const. The other side of this coin however is that you may decide one day that you do need to modify the variable in the function, which would require that you change the signature, or make a local copy. In addition, which marking is as const does add some documentation for the maintenance programmer, it also adds documentation for the client programmer -- but this documentation is misleading at best. It implies certain semantics to the caller that do not exist.

But whatever you do, you need to be consitant. Either make all your by-value parameters const, or none of them. Inconsitancy will destroy any of the documentary benefits you gain by taking either side.

If it's a 3 line function, the const doesn't help much.

But if you have to understand and maintain a 300 line function, it can be a very important clue that a local variable or parameter will not be changed before line 289, where it is used.

Pro const:

• prevents the argument from being accidentally modified within the callee

Contra const:

• adds clutter without providing useful information to the caller
• implementation changes (ie removing the qualifier) will change the interface

The ideal solution would be to provide the const only in the declaration which is part of the function definition. However, the C standard does not allow this; it will work as expected in all reasonable implementations of the C language, though.

I'd say const would add absolutely nothing to your code.