Understanding const

[micpayne]

Given these example variations of the use of const:

Class::Constructor(const type* argument) //constant pointer to a constant value
	                   	         //*argument = 3: illegal
					 //argument = &otherVariable: legal

Class::Constructor(const type &argument) //... need help with this one

Class::Method(const type* const argument) //constant pointer to a constant value
					  //*argument = 3: illegal
					  //argument = &otherVariable: illegal

Class::Method(type argument) const //protects *this 

I'm a student at UAT and am trying to wrap my head around the use of const. I'm slowly making progress per the comments above, but wouldn't mind some additional insight (most notably the one using &argument). Furthermore it is my understanding that the use of const speaks to the compiler directly and does not generate run-time errors. Is using const another form of OO data protection that is the responsibility of the coder to integrate?

Anything to add to the above comments? I wouldn't mind some corrections on my nomenclature as well. Thanks!

[Disch]

The easy way to remember it is to read delcarations "backwards", from right to left. Pronounce the * as "pointer to" and & as "reference to"

So

const type* argument would be read as "argument is a pointer to a const type".

Meaning the pointer itself is not const (argument = &foo is OK)
but the data it points to is const (*argument = foo is error)

Likewise const type* const argument would be "argument is a const pointer to a const type".

Meaning the pointer itself is const (argument = &foo is error)
and so is the data it points to (*argument = foo is error)

const type& argument just means that argument is a reference to a const type. Therefore argument cannot be modified (argument = foo is an error)

Furthermore it is my understanding that the use of const speaks to the compiler directly and does not generate run-time errors.

Usually, yes. There are instances where some memory might actually be read-only and therefore is strictly const at runtime. However that isn't very often.

Is using const another form of OO data protection that is the responsibility of the coder to integrate?

It's kind of a code clarity thing. Passing things by const reference or const pointer tells you that the function will not modify the object you're passing.

void Foo(const Obj& v);
void Bar(Obj& v);

int main()
{
  Obj o;

  Foo(o);  // I can rest easy knowing this will not modify o
  Bar(o);  // on the other hand, this likely will modify o
}

[Mathhead200]

//To add...
void Foo(const Obj& v);
void Bar(Obj& v);

int main()
{
  const Obj o; //For whatever reason, o is constant and should not change state.

  Foo(o);  // Fine; pass the const o as a reference because it will not be changed.
  Bar(o);  //Error; we can't just remove the const modifier as then we might modify o.
}

Class::Method(type argument) const //protects *this
//Not only that, but now Method can be invoked on const Class instances also. 

[quirkyusername]

I'd just like to add that compilers can sometimes make optimisations that they wouldn't otherwise be able to when it knows that a certain object is const. Don't look too much into this though, using const is mainly as disch said about code clarity and easily being able to see exactly what you or a method may do to an object.

[micpayne]

Thanks for the time on this folks.

 Foo(o);  // Fine; pass the const o as a reference because it will not be changed.
  Bar(o);  //Error; we can't just remove the const modifier as then we might modify o. 

In the above, both are still passed by reference, correct?

and...
void Bar(Obj& v);
The compiler throws a tantrum because of the inconsistent use of const within the parameters?

In other languages, something was made constant upon declaration and that was all that was needed. In this case, it seems to facilitate in program readability. . . maybe?

[zb0S216C]

In addition to all of the other posts, const is a type qualifier, just like __unaligned, volatile, and restrict/__restrict. Type qualifiers give you greater control over the compiler optimizations.

_Wazzak

[Mathhead200]

Well when your working with user defined data types const takes on the meaning of, however to programer wanted an instance of that class to behave when marked as const. The only thing you can be sure of is that a const object will not change it's state (excluding while still in its constructor.)

Remember that const Object &obj is a reference to a constant object. The reason you can't do
obj = anotherObj is because that invokes the method __ operator=(Object)
or __ operator=(Object&) which is usually not a constant method as it most likely will change the state of the object it's invoked on.