C/C++: Why we go for const-correctness (Rant)

[Octocontrabass]

In any case, this is for nothing useful. Honestly, I think at least for C using const for arguments is a plain dumb nonsense.

In your examples it doesn't make a whole lot of difference, since arguments are passed by value. Even if the function does modify its arguments, they don't affect the rest of the program.

But it's a much bigger difference once you consider pointers. For example, look at these two function signatures:

Code: Select all

int function1(int * a);
int function2(const int * a);

The first function can modify its argument, and it can do it in a way that affects the caller. The second function can't. This is the situation where using const for arguments makes sense.

Edit: fixed dumb mistake

[zaval]

In your examples it doesn't make a whole lot of difference, since arguments are passed by value. Even if the function does modify its arguments, they don't affect the rest of the program.

But it's a much bigger difference once you consider pointers. For example, look at these two function signatures:

Code: Select all

int function1(int * a);
int function2(int * const a);

The first function can modify its argument, and it can do it in a way that affects the caller. The second function can't. This is the situation where using const for arguments makes sense.

Maybe it makes. Neither I nor Wajideus are in the committee, so the C language is not endangered.

Just out of curiosity, let's consider your example, let's imagine our compiler ignores const in arguments as an unneeded noise and lets function2() change its argument which is a copy of the value of the pointer supposed to be a constant:

Code: Select all

int function2(int * const a){
 *a = NewValue; /* this is valid for both functions */
 ...
 a = AnotherPointer; /* this is only valid for function1() */
 ...
 return STATUS_EVERYTHING_IS_JUST_AWESOME;
}

What could happen with the caller? why should it go nuts because the callee changed its own parameters?
In C, function arguments are yet other function's local variables. passing the information that the pointer the value of which I am copying for you, is not about to be changed, has a little of usability. Because for changing the value of that pointer, one would need an address of that pointer, and what function2 gets is only a copy of the value of the pointer.

[Octocontrabass]

Well...

It would help if I proofread my posts before I submit them.

Try again with my fixed function2 signature:

Code: Select all

int function2(const int * a);

[zaval]

finally we've found something that might have some sense with respect to using const in arguments. like passing a pointer to a structure supposed to aggregate a set of constants. I am not against this. not that it's a vitable feature, rather a corner case, but of course not as nonsensical as making all arguments constant.

[Solar]

Const Correctness is not a contest of "how many 'const' can I put in there".

It is about using const wherever it makes sense.

Consider:

Code: Select all

int foo( char * string );

versus

Code: Select all

int foo( char const * string );

Or, for C++,

Code: Select all

class foo
{
    public:
        int bar( std::string & s );
};

versus

Code: Select all

class foo
{
    public:
        int bar( std::string const & s ) const;

The big problem with it is, if the implementor of a function or class did not label "const" where applicable, you cannot call those functions on constant arguments or objects, no matter whether the function actually changes the argument / object or not. So, not working "const correct" here means that your clients cannot work const-correct either, which is a royal PITA.

----

PS: All other things aside, of course a function can "cast away" any "const". The keyword is a promise, a contract, not an enforcement. (Just like "private:" doesn't really make member variables inaccessible / secret.) But you can't make promises or contracts if your workers don't make (or honor) them.

[bluemoon]

Yes, many people forget to write the `const` method case, e.g.

Code: Select all

uint8_t* get_ptr() { return m_buffer; }
const uint8_t* get_ptr() const { return m_buffer; }

without the const method you have to pass the non-const object around, which usually give you surprise when someone feel like to modify it.

[Solar]

You return a non-const pointer to a member one more time, and I'll go legendary on your backside.

(Actually, you shouldn't return pointers to members, period, unless your class is something like std::shared_ptr...)

[bluemoon]

You return a non-const pointer to a member one more time, and I'll go legendary on your backside.
(Actually, you shouldn't return pointers to members, period, unless your class is something like std::shared_ptr...)

Well it is a very special case of a buffer class which provide a bit more utility and performance than vector.
The point is most people don't write those `const` group of functions and force you to pass non-const objects around.

[Wajideus]

finally we've found something that might have some sense with respect to using const in arguments. like passing a pointer to a structure supposed to aggregate a set of constants. I am not against this. not that it's a vitable feature, rather a corner case, but of course not as nonsensical as making all arguments constant.

This was the situation when I was talking about const implying memory ownership. What you're wanting in this scenario is to pass a copy of the structure to a function, not a link to it. The caller owns the original, the callee owns the copy.

When you start working with large structs though, you can see how this can quickly become inefficient if you don't make the arguments const by default. A const copy is equivalent to an immutable link.