By Igor


2019-07-10 11:11:09 8 Comments

I know that it is not allowed to modify the state of a constant object but why can the destructor change this state?

class A
{
public:
    ~A()
    {
        i = 2; //?
    }

    void test() const
    {
        //i = 1; //Not allowed
    }

    int i = 0;
};

int main()
{
    const A o;
    o.test();
}

3 comments

@eerorika 2019-07-10 11:22:44

why can the destructor change this state?

Because it may be useful to be able to change the state of objects in the destructor whether they were const or not.

And because it doesn't matter for encapsulation. The lifetime has ended, so no-one can see the object in the modified state anyway.

And because the standard (quoting from the draft) says so:

[class.dtor]

The address of a destructor shall not be taken. A destructor can be invoked for a const, volatile or const volatile object. const and volatile semantics ([dcl.type.cv]) are not applied on an object under destruction. They stop being in effect when the destructor for the most derived object ([intro.object]) starts.

@lubgr 2019-07-10 11:21:43

As soon as the destructor is executed, the lifetime of the object has already ended. It doesn't make any sense to disallow operations that modify state, because this modified state will never be seen by any caller that is part of well-behaved code. Also, once the lifetime has ended, it doesn't matter whether the object has been const beforehand or not. This is the same reasoning behind constructors not being const-qualified special member functions. They setup an object before its lifetime. Once it's alive, it can be const, beforehand, that makes no sense and would be of little value.

@Gem Taylor 2019-07-10 11:14:25

For the same reason that the constructor can change the state! These two methods own the object and can do anything they like to create and destroy it.

In particular, the object may have some allocated resources, or contain smart pointers. These must be destroyed by the destructor.

Just wait until you find out about mutable members and rval references!

@eerorika 2019-07-10 11:17:54

Smart pointers don't need to be modified by the destructor though. That's different from being destroyed.

@Gem Taylor 2019-07-10 12:56:43

@eerorika They do... they have to release a hold count on the thing they reference.

@eerorika 2019-07-10 13:00:58

I don't know of all reference counted pointer implementations, but isn't the count typically stored separately? If it is stored in the pointer itself, then wouldn't every single copy of the pointer be modified whenever refcount changes.

@MSalters 2019-07-11 07:15:56

There's not even a need for a refcount - smart pointers can be implemented as a circular list. And unique_ptr by design does not have a refcount either.

Related Questions

Sponsored Content

21 Answered Questions

[SOLVED] Why should I use a pointer rather than the object itself?

  • 2014-03-03 11:54:16
  • gEdringer
  • 286928 View
  • 1487 Score
  • 21 Answer
  • Tags:   c++ pointers c++11

16 Answered Questions

[SOLVED] Why can templates only be implemented in the header file?

7 Answered Questions

[SOLVED] Why is argc not a constant?

24 Answered Questions

[SOLVED] Image Processing: Algorithm Improvement for 'Coca-Cola Can' Recognition

10 Answered Questions

5 Answered Questions

4 Answered Questions

[SOLVED] Why not non-const reference to temporary objects?

11 Answered Questions

[SOLVED] How come a non-const reference cannot bind to a temporary object?

3 Answered Questions

[SOLVED] It is useful to put a constant destructor?

1 Answered Questions

[SOLVED] function overload of a constant object

  • 2015-09-14 21:54:23
  • Alex Goft
  • 35 View
  • 1 Score
  • 1 Answer
  • Tags:   c++ overloading

Sponsored Content