C++, Classes, Const, and strange syntax

I was re-reading c++ primer(4th ed.) today - the s开发者_运维知识库ection on member functions and const references etc, and I came up with this wierd little program:

using std::cout;
using std::endl;

class ConstCheater
{
public:
    ConstCheater(int avalue) : ccp(this), value(avalue) {}
    ConstCheater& getccp() const {return *ccp;}
    int value;
private:
    ConstCheater* ccp;
};

int main()
{
    const ConstCheater cc(7); //Initialize the value to 7
    cout << cc.value << endl;
    cc.getccp().value = 4;    //Now setting it to 4, even though it's const!
    cout << cc.value << endl;
    cc.value = 4;             //This is illegal
    return 0;
}

My question is - why does c++ allow syntax such as this? Why can I edit normal data members in a class when it's declared const? Isn't the POINT of const to make it so that you can't modify values?

Even though getccp() is a const method it makes no promises what you do with the reference it returns. The method itself does not modify the object and therefore does not break the rules.

If it returned a const ConstCheater& then that would be different.

As your example shows, there is much more complexity to const than just applying it to an object. the C++ FAQ has a section on const correctness and in particular it covers the case you are highlighting here.

I'd say the answer by Tony that you marked as correct is incorrect, and the answer by Michael Burr is correct.

To put what he said more clearly (for me at least):

There are two potential places for misunderstanding:

1. The way implicit const works
2. The way that this is interpreted during construction of a const object

1. Implicit Const

Implicit const (the constification internal to ConstCheater when it is made const) doesn't turn cc into a pointer-to-const but rather a const-pointer, that is to say when you do this:

  const ConstCheater cc(7); 

Internally goes from:

  ConstCheater * ccp;

...to...

  ConstCheater * const ccp;

...rather than the...

  const ConstCheater * ccp;    

that may have been expected.

2. Construction of const object

The stranger thing is though is that this is allowed to be passed to cpp's initializer in the constructor since this, one would think, should be treated as a pointer-to-const, and thus not a valid value to pass to a const-pointer.

That is to say one might expect:

 ...: ccp(this) ... // expected to fail but doesnt

to fail because conceptually you might expect that this was (somewhat) equivalent to:

 const ConstCheater         cc(7);
 const ConstCheater * const this = &cc; // const-pointer-to-const

and thus you would think that:

 ConstCheater * const ccp = this; //expected error!

would fail! But it doesn't because apparently during construction apparently this is treated specially as if it was:

 const ConstCheater * this = &cc; 

and thus the object is effectively not const during construction.

I'm not sure I understand completely the reasoning, but Michael Burr points out there appears to be a logical and technical barrier to providing the expected behavior so the standard seems to carve out the current somewhat odd behavior.

I recently asked a related question which was: Why does C++ not have a const constructor? but thus far haven't really understood completely the reasoning why it would be untenable, though I suppose it would place a burden on C++ developers to have to define an awkward const constructor for any class they'd like to create const object of.

The constructor is allowed to modify the value of a const object, yes. But if it weren't, what could it do?

Since the constructor has such access, it can "forward" it to someone else or "save" it for later. Of course, doing so might be a bad idea.

This is one instance where the safety mechanisms of C++ do not prevent you from building an ill-formed program. C++ is anything but foolproof. So, just be careful!

Objects do not become const until after their constructors finish doing their thing. So this is a pointer to non-const memory when you store it, but changes shortly after. That's why it allowed the assignment in the first place, because you did nothing wrong. That means cpp is a pointer to const, but the compiler doesn't realize that. It has no way to; you declared it non-const, after all. This is still undefined behavior, it's just not the type your compiler can ever really hope to help you catch.

The real issue isn't the behavior of ConstCheater::getccp() - it's that there's no error on the line:

const ConstCheater cc(7);

which initializes a non-const pointer with what should be a const this pointer. However, constructors cannot be const (9.3.2/5, but a bit of thought should make it obvious why). So the constructor is allowed to initialize a non-const pointer with a pointer to a const object (or an object that's 'about to become' const). That's the hole you're driving though.

As to why it's allowed, I imagine it would be difficult for the standard to try to close the hole since it would have to enumerate all the ways that a constructor's this would have to be treated const and all the ways it would have to be treated non-const when constructing a const object. That seems like a pretty difficult task.

Your object is not entirely immutable: it's just the reference you created to point to it that's constant.

What you are making const is the reference to a ConstCheater. Nothing in ConstCheater is making value a const.

const qualifier restricts to call non-const methods on your object, so the problem is your design that allows you to give non-const reference to a member by a const method. The common approach is

      Member& getccp()       {return *member;}
const Member& getccp() const {return *member;} 

In some cases when logical constness of your object don't suffer from external modification of it's member you can allow

      Member& getccp() const {return *member;}

Another example of difference in logical and formal constness is the mutable members. I.e. mutable can be some term that was computed at the last const method's invoke, if you will get the same input at next invoke you can easily return stored value.