Hi,
To include const in a function declaration, does that actually ensure that the function does not modify the arguments passed to the function? Or is it just a sort of promise to the user from the programmer?
e.g.
Code:size_type size() const { return avail - data; }
It is a promise that is enforced by the compiler unless the member variable that is modified is declared mutable or you circumvent it with a cast like const_cast. The former has a legitimate use where changing the member variable does not change the observable state of the object, so the object remains logically constant.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Ok well I'm trying to make sense of these two lines my professor wrote in an example program to simulate STL vectors:
I understand that the second one has a return type of const T so that the return value can only be used as an r-value but I don't understand why the 2nd const is there after the parameter list and not there in the first line if they both have the same implementation and don't modify anything...Code:T & operator[](size_type i) { return data[i]; } const T & operator[](size_type i) const { return data[i]; }
If the function promises that it will not modify anything - or let anything else modify anything, it cannot very well return a reference (non-const) so other parts of the program can modify it, now can it?
The whole purpose of the const is that the function promises that any class data will never change, or that it will do anything that can cause the class data to change.
True, the functions don't modify anything, but the first one returns a reference to a member variable that can be used to modify the object.
Kurt
Oh ok I think I get it now...
So the const in the function declaration that follows the parameter list is not just a promise that the function itself won't modify the arguments but it is also a promise that what it returns won't be tampered with even after the function returns. Correct?
Last edited by Canadian0469; 11-15-2008 at 03:23 PM.
The const after the functions parameter list is a promise that the object itself is not changed by calling that function.
Kurt
Oh ok so I had the wrong idea. Thanks for clearing that up for me Kurt, that one sentence totally demystified it for me!
Also, its use may be quite useful to state here...
Let's take an object called 'Array' with a single function (the one you typed here):
Now let's say we have a const Array. We can't call this operator[], since the compiler thinks the function *might* change the object. Even if the returned variable would be a reference; nothing would actually be changed, but the compiler still doesn't allow the function call in case the internals of the objects are changed by the function.Code:T & operator[](size_type i) { return data[i]; }
The second const makes sure that it *may* be called from a const object. So if you have a "const Array", it will call the const-function (the second), and if you have a non-const Array it will call the non-const version.
This way, when creating an object, you can actually indicate what is and is not accepted as a change on a const object.
Well, obviously, a const object promises not to change anything, so it cannot call any functions that can change something. Which also makes const correctness an important thing.
"promises not to change anything" is far too vague.
A const member promises not to change the logical state of its containing object.
What are the consequences of this?
1) You cannot modify members that are part of the logical state of the object.
2) You can modify members that are not part of the logical state of the object (e.g. some kind of cache).
3) You cannot make accessible a non-const reference to something that is part of the logical state of the object. You cannot call functions passing such a reference, and you cannot return such a reference.
In practice, this is enforced by the compiler by making type of the this pointer 'const T*'. Consequently, you cannot modify any direct members of the object, unless they're mutable.
However, you could still modify indirect members, i.e. data pointed to by member pointers or references. It's up to you as the programmer to ensure you don't modify them if they're part of the logical state. That's not always the case.
In the case of a vector (or any other container), the indirect members, i.e. the allocated data, are very much part of the logical state, so vector does not provide a const accessor that returns a non-const reference.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
