Const correctness for value parameters

Question

I know there are few question about const correctness where it is stated that the declaration of a function and its definition do not need to agree for value parameters. This is because the constness of a value parameter only matters inside the function. This is fine:

// header
int func(int i);

// cpp
int func(const int i) {
    return i;
}

Is doing this really a best practice? Because I've never seen anyone do it. I've seen this quotation (not sure of the source) in other places this has been discussed:

"In fact, to the compiler, the function signature is the same whether you include this const in front of a value parameter or not."

"Avoid const pass-by-value parameters in function declarations. Still make the parameter const in the same function's definition if it won't be modified."

The second paragraph says to not put the const in the declaration. I assume this is because the constness of a value parameter is meaningless as part of a interface definition. It is an implementation detail.

Based on this recommendation, is it also recommended for the pointer values of pointer parameters? (It is meaningless on a reference parameter since you can't reassign a reference.)

// header
int func1(int* i);
int func2(int* i);

// cpp
int func1(int* i) {
    int x = 0;

    *i = 3; // compiles without error
    i = &x; // compiles without error

    return *i;
}
int func2(int* const i) {
    int x = 0;

    *i = 3; // compiles without error
    i = &x; // compile error

    return *i;
}

Summary: Making value parameters is useful to catch some logic errors. Is it a best practice? Do you go to the extreme of leaving the const out of the header file? Is it just as useful to const pointer values? Why or why not?

Some references:

C++ const keyword - use liberally? Use of 'const' for function parameters

An example of when const value parameters are useful:

bool are_ints_equal(const int i, const int j) {
    if (i = j) { // without the consts this would compile without error
        return true;
    } else {
        return false;
    }
    // return i = j; // I know it can be shortened
}

Answer 1

My take on it:

It's not a bad idea, but the issue is minor and your energy might be better spent on other things.

In your question you provided a good example of when it might catch an error, but occasionally you also end up doing something like this:

void foo(const int count ...)
{
   int temp = count;  // can't modify count, so we need a copy of it
   ++temp;

   /* ... */
}

The pros and cons are minor either way.

Answer 2

I've read many times that making value parameters in a function const is a bad thing to do because it's unnecessary.

However, I find it occasionally helpful to me as a check that my implementation doesn't do something I don't intend (as in the example at the end of your question).

So, while it may not add value to the caller, it does sometimes add a small bit of value to me as an implementer, and it doesn't take anything away from the caller. So I see no harm using it.

For example, I may be implementing a C function that takes a couple pointers to a buffer - a pointer to the start, and a pointer to the end. I'm going to put data in the buffer, but want to ensure that I don't overrun the end. So inside the function there's code that will increment a pointer as I'm adding data to it. Making the pointer to the end of the buffer a const parameter will ensure that I don't code up a bug that accidentally increments the end boundary pointer instead of the pointer I really should be incrementing.

So a fillArray function with a signature like this:

size_t fillArray( data_t* pStart, data_t* const pEnd);

will prevent me from accidentally incrementing pEnd when I really mean to increment pStart. It's not a huge thing, but I'm pretty sure everyone who has programmed for any period of time in C has run across such a bug.

Answer 3

Unfortunately, some compilers (I'm looking at you, Sun CC!) incorrectly differentiate between arguments declared const and ones not declared so, and you can get errors about undefined functions.

Answer 4

I think this is dependent on your personal style.

It doesn't add or subtract to what clients can pass to your function. In essence it's like a compile-time assertion. If it helps you to know that value won't change, go ahead and do it, but I don't see a big reason for others to do it.

One reason I might not do it is that the const-ness of the value parameter is an implementation detail that your clients don't need to know about. If you later (purposely) change your function so that it actually does change that value, you will need to change the signature of your function, which will force your clients to re-compile.

This is similar to why some people recommend having no public virtual methods (the functions virtual-ness is an implementation detail that should be hidden from clients), but I'm not in that particular camp.

Answer 5

If there is const keyword present; it means value of 'i' (which is const type) can not be modified. If value of 'i' is changed inside foo function compiler will throw error: "

Can not modify const object

But changing '*i' (i.e. *i = 3;)means you are not changing value of 'i' but value of address pointed by 'i'

Actually,the const function is appropriate for large objects that should not be altered by function.

Answer 6

We all have to untangle someone else's C++ code from time to time. And that someone else's C++ code is a complete mess by definition :D.

So the 1st thing I always do to decipher it (local & global data flow) is put const in every variable definition until compiler complains. This also means const-qualifying value arguments, and it really helps avoiding variables that have been modified in the middle on the function without me noticing it...

So I really appreciate when that someone else has const everywhere (including value parameters) :D

Answer 7

I like const correctness for situations like this:
void foo(const Bar &b) //I know b cannot be changed
{
//do something with b
}

This lets me use b without fear of modifying it, but I don't have to pay the cost of a copy constructor.