8

I was surprised to find this "hole" in "const"ness:

#include <stdio.h>

class A
{
  int r ;
public:
  A():r(0){}

  void nonconst()
  {
    puts( "I am in ur nonconst method" ) ;
    r++;
  }
} ;

class B
{
  A a ;
  A* aPtr ;

public:
  B(){ aPtr = new A() ; }

  void go() const
  {
    //a.nonconst() ;      // illegal
    aPtr->nonconst() ;  //legal
  }
} ;

int main()
{
  B b ;
  b.go() ;
}

So basically from const method B::go(), you can invoke the non-const member function (aptly named nonconst()) if object of type A is referenced by a pointer.

Why is that? Seems like a problem (it kind of was in my code, where I found it.)

curiousguy
  • 8,038
  • 2
  • 40
  • 58
bobobobo
  • 64,917
  • 62
  • 258
  • 363
  • This is rather unexpected. I ran it through g++ 4.2.1 on a Mac, and the code compiled (much to my surprise). I'm curious to see the answer to this. – Sergey Kalinichenko Dec 19 '11 at 03:29
  • 1
    This behavior is often surprising the first time you stumble upon it. Some time ago, I asked [this question](http://stackoverflow.com/q/4729820/20984) to know if there were solutions for propagating constness to pointee objects. – Luc Touraille Jun 01 '12 at 09:16

3 Answers3

11

When and object of type B is const, then all of its members are const, which means its two members are, for the duration of B::go(), effectively

A const a;
A * const aPtr;

The first is a constant object of type A, on which you can only call const member functions. The second, however, is a constant pointer to a non-constant A. You could not legally say aPtr = <anything> from within the function B::go(), since that would modify aPtr, which is constant.

A pointer to a constant A would be declared as A const* aPtr or const A* aPtr, which would then make calling the non-constant A::nonconst() illegal.

Dave S
  • 20,507
  • 3
  • 48
  • 68
6

The "const-ness" of an object does not extend to other objects through pointers. In your example, the const part is either the entire object a, or the pointer aPtr. Because aPtr is a A * and not a const A *, you are allowed to call a non-const method.

If you change

A* aPtr ;

to

const A* aPtr ;

then you will not be able to call aPtr->nonconst().

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • Hmm.. that would render the object `A` nearly useless if you ever need to use it's non-const facilities. I thought marking a method `const` is a contract not to change state information of the object... I thought __all__ members should get marked `const`, even the ptrs! I had a `dirty` bit that got set whenever a non-const method was invoked. But now, even some `const` methods should set the dirty bit! What a surprise. – bobobobo Dec 19 '11 at 03:37
  • 2
    When an object is `const`, all its members are `const` also. You cannot change what `aPtr` points to inside a `const` method. However, your current object being `const` doesn't affect the `const`-ness of any *other* object. – Greg Hewgill Dec 19 '11 at 03:40
  • @bobobobo "_I thought all members should get marked const_" Yes, and they are, of course. That does not make other objects const, hopefully. – curiousguy Dec 19 '11 at 04:39
0

Language definition of const

I was surprised to find this "hole" in "const"ness:

There is none.

const applies uniformly to all class members: in a const member function of class C, this has type const C *, so for a member C::mem declared as type T:

class C {
// ...
    T mem;
};

this->mem has type const T.

Please take type to discern what is the declared type T and the corresponding const-qualified type for all the members.

Seems like a problem (it kind of was in my code, where I found it.)

Just because the systematic application of rules does not do what you expected does not mean there is a problem with the rules, it means there is a problem with your expectations.

You should write down your expectations to see that you expected a non uniform application if const to different types.

When you program, you have to reason logically. You should infer things, not expect them when there is no logical reason.

Using const correctly

Why is that?

Your classes being called A and B, it's pretty hard to understand what constitute logical state and what does not. ;) You ask a "moral" question (not a question only on legal/illegal C++ programs), and your code fragment has no "moral" value. If you actually post relevant code, we might make some "moral" judgements about it.

Logical state

You should declare const the functions that do not change the "logical state" of the object it's applied to.

It means you have to define what is the "logical state" of your class instances: it's an abstract concept, and only you can define it, because it's a high level concept. The "logical state" relates to the problem your class should solve.

Then you can discern which variables contribute to the logical state: does *(b.aPtr) contribute to the logical state of b?

Closely related questions

Do you know about the copy constructor?

About the copy assignment operator?

About the destructor?

curiousguy
  • 8,038
  • 2
  • 40
  • 58