Is an object allowed to legally change its type during its lifetime in C++?

Question

I have this code:

class Class {
public:
    virtual void first() {};
    virtual void second() {};
};

Class* object = new Class();
object->first();
object->second();
delete object;

that I compile with Visual C++ 10 with /O2 and have this disassembly:

282:    Class* object = new Class();
00403953  push        4  
00403955  call        dword ptr [__imp_operator new (4050BCh)]  
0040395B  add         esp,4  
0040395E  test        eax,eax  
00403960  je          wmain+1Ch (40396Ch)  
00403962  mov         dword ptr [eax],offset Class::`vftable' (4056A4h)  
00403968  mov         esi,eax  
0040396A  jmp         wmain+1Eh (40396Eh)  
0040396C  xor         esi,esi  
283:    object->first();
0040396E  mov         eax,dword ptr [esi]  
00403970  mov         edx,dword ptr [eax]  
00403972  mov         ecx,esi  
00403974  call        edx  
284:    object->second();
00403976  mov         eax,dword ptr [esi]  
00403978  mov         edx,dword ptr [eax+4]  
0040397B  mov         ecx,esi  
0040397D  call        edx  
285:    delete object;
0040397F  push        esi  
00403980  call        dword ptr [__imp_operator delete (405138h)]  

Note that at 00403968 the address of the object start (where vptr is stored) is copied into esi register. Then at 0040396E this address is used to retrieve the vptr and the vptr value is used to retrieve address of first(). Then at 00403976 the vptr is retrieved again and is used to retrieve the address of second().

Why is vptr retrieved twice? Could the object possible have its vptr changed in between calls or is it just an underoptimization?

Answer 1

Why is vptr retrieved twice? Could the object possible have its vptr changed in between calls or is it just an underoptimization?

Consider:

object->first();

This call may destroy the object and create a new one in the same chunk of memory. Hence, after this call no assumptions can be made about the state. E.g.:

#include <new>

struct Class {
    virtual void first();
    virtual void second() {}
    virtual ~Class() {}
};

struct OtherClass : Class {
    void first() {}
    void second() {}
};

void Class::first() {
    void* p = this;
    static_assert(sizeof(Class) == sizeof(OtherClass), "Oops");
    this->~Class();
    new (p) OtherClass;
}

int main() {
    Class* object = new Class();
    object->first();
    object->second();
    delete object;
}

Compilers may optimize away unnecessary register loads if that function is inline and/or link-time code generation is used.

---

As DeadMG and Steve Jessop noted the above code exhibits undefined behaviour. According to 3.8/7 of C++ 2003 Standard:

If, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, a new object is created at the storage location which the original object occupied, a pointer that pointed to the original object, a reference that referred to the original object, or the name of the original object will automatically refer to the new object and, once the lifetime of the new object has started, can be used to manipulate the new object, if:

• the storage for the new object exactly overlays the storage location which the original object occupied, and
• the new object is of the same type as the original object (ignoring the top-level cv-qualifiers), and
• the type of the original object is not const-qualified, and, if a class type, does not contain any non-static data member whose type is const-qualified or a reference type, and
• the original object was a most derived object (1.8) of type T and the new object is a most derived object of type T (that is, they are not base class subobjects).

The above code doesn't satisfy requirement 2 from the above list.

Answer 2

It is stored in esi to be saved between the calls to different functions.

The Microsoft convention says

The compiler generates prolog and epilog code to save and restore the ESI, EDI, EBX, and EBP registers, if they are used in the function.

so the pointer stored in esi will remain, but the this pointer in ecx might not.

Answer 3

To answer the question from the title first:

Yes, an object from a derived class changes its type during construction and destruction. This is the only case.

The code in the body of the question is different. But as Maxim correctly notes, you just have a pointer. This pointer may point (at different times) to two different objects residing at the same address.