OSDev.org
https://forum.osdev.org/

C/C++: Why we go for const-correctness (Rant)
https://forum.osdev.org/viewtopic.php?f=13&t=32603
Page 2 of 2

Author:  Octocontrabass [ Sun Dec 03, 2017 1:41 pm ]
Post subject:  Re: C/C++: Why we go for const-correctness (Rant)

zaval wrote:
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:
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

Author:  zaval [ Sun Dec 03, 2017 3:14 pm ]
Post subject:  Re: C/C++: Why we go for const-correctness (Rant)

Octocontrabass wrote:
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:
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. :mrgreen:

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:
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.

Author:  Octocontrabass [ Sun Dec 03, 2017 3:45 pm ]
Post subject:  Re: C/C++: Why we go for const-correctness (Rant)

Well...

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

Try again with my fixed function2 signature:
Code:
int function2(const int * a);

Author:  zaval [ Sun Dec 03, 2017 4:21 pm ]
Post subject:  Re: C/C++: Why we go for const-correctness (Rant)

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.

Author:  Solar [ Mon Dec 04, 2017 2:49 am ]
Post subject:  Re: C/C++: Why we go for const-correctness (Rant)

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:
int foo( char * string );


versus

Code:
int foo( char const * string );


Or, for C++,

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


versus

Code:
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.

Author:  bluemoon [ Mon Dec 04, 2017 6:39 am ]
Post subject:  Re: C/C++: Why we go for const-correctness (Rant)

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

Code:
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.

Author:  Solar [ Mon Dec 04, 2017 6:50 am ]
Post subject:  Re: C/C++: Why we go for const-correctness (Rant)

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

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

Author:  bluemoon [ Mon Dec 04, 2017 7:06 am ]
Post subject:  Re: C/C++: Why we go for const-correctness (Rant)

Solar wrote:
You return a non-const pointer to a member one more time, and I'll go legendary on your backside. :twisted:
(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.

Author:  Wajideus [ Mon Dec 04, 2017 7:19 am ]
Post subject:  Re: C/C++: Why we go for const-correctness (Rant)

zaval wrote:
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.

Page 2 of 2 All times are UTC - 6 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/