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?

Mindy

Weird. I thought it should all be a no-op. It's probably an underoptimization, if it looked inside the functions it could have seen that neither of them change esi. – Drumlin

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.

Finial

@LuchianGrigore: Maybe LTCG doesn't help yet, but it's an optimisation that's available to potential future compilers. – Rahman

@LuchianGrigore: gcc-4.7.1 optimizes the original code as posted into a call to operator new() followed by a call to operator delete() with -O3. Do you care to provide any supporting evidence for you claim? – Finial

@MaximYegorushkin you used gcc with visual C++? Because otherwise, you're not answering the question. This is about a specific compiler with a specific setting (-O2). And with visual C++, -O2 with link-time code generation yields the same result. – Drumlin

Not really. Creating anything except another Class in that space would be a giant pile of UB. The compiler does not have to concern itself with this potential scenario. – Antheridium

@DeadMG: Creating anything except another Class in that space would be a giant pile of UB. Well, not really. Do you care to provide any supporting evidence to this bold claim? – Finial

@Maxim: object->second() is UB. The pointer object does not validly refer to any object, certainly not the newly-created object of type OtherClass. See 3.8/7 in the standard. Your code violates the second bullet point ("the new object is of the same time as the original object") or the fourth ("they are not base class sub-objects"), depending whether it's the complete object or its Class base that you think object refers to. In fact it refers to neither, although in practice of course it still contains the same address. So you won't see a problem unless optimization screws you. – Vaudeville

@SteveJessop: The pointer object does not validly refer to any object, certainly not the newly-created object of type OtherClass. I don't see why it wouldn't validly refer to an object. After the call to object->first() object pointer validly refers to the newly created OtherClass object, does it not? – Finial

@Maxim: no, it does not. 3.8/7 specifically states that it refers to the new object if the conditions are met. The conditions are not met. There's nothing else anywhere in the standard to say that it refers to the new object (if there was something, then what would be the point of 3.8/7 carefully defining those conditions, when the pointer refers to the new object whether they're met or not?). So it doesn't refer to the new object. It used to refer to the old object, but you destroyed the old object. – Vaudeville

That is, as far as the standard is concerned. It's possible that MSVC has taken it upon itself, as an extension, to allow the pointer to refer to the new object, and that's why vptr is re-loaded. But there are other reasons vptr might have been re-loaded, so we can't conclude from this code that MS guarantees that will always happen. – Vaudeville

@SteveJessop: I've taken a look at 3.8/7 and it does indeed require the new object to be of exactly the same type for the pointer to remain valid. That's a bit surprising that it doesn't allow for a derived class of the same size. May be it is to allow a compiler to avoid reloading the vtable pointer after each virtual call (an optimization MSVC doesn't do here). – Finial

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.

Spurt

Okay, the start of object is stored in esi, but why is vptr read twice? – Mindy

Also keeping the vptr would require an additional register, like edi, which would then have to be saved and restored. Would that improve the code? Hard to tell. – Spurt

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.

Physician