Can I delete a union component without checking whether it stores that object?

Question

I mean the following. I have a few classes which inherit the same base class. Union consists of pointers of these classes:

#include "stdio.h"

class A {
public:
    A() { printf("A\n"); }
    virtual ~A() { printf("~A\n"); }
};

class B  : public A {
public:
    B() { printf("B\n"); }
    virtual ~B() { printf("~B\n"); }
};

class C : public A {
public:
    C() { printf("C\n"); }
    virtual ~C() { printf("~C\n"); }
};

int main() {
    union {
        B* b;
        C* c;
    } choice;
    choice.b = new B();
    delete choice.c;    //We have B object, but deleting C
    return 0;
}

It seems to work, but I'm not sure if it isn't implementation-specific behaviour. Can I use such weird deleting method or should I remember a type of stored object and delete it respectively?

P.S. I use C++11 and want it works on both GCC and Visual C++ (2012 and higher). In a real project I have more complex class hierarchy but all of them are successors (directly or indirectly) of the same abstract base class

Answer 1

This is a double dose of undefined behavior. First, you can't delete a B through a pointer to C. §5.3.5 [expr.delete]/p3:

In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined.

Second, accessing the inactive member of a union is also undefined behavior in C++.

There's no need to use an union here anyway. B and C share the same base class, so you can just store the pointer in an A *.

Answer 2

You shouldn't. You are only allowed to read from the union member you last wrote into and you're only allowed to delete an object through a pointer to a base class (if it has a virtual destructor). It may seem to work now, but you may find it to break randomly in the future, usually due to an aggressive optimizer.

Why don't you store a pointer to A instead of the union?

Answer 3

As it has been said in other answer, this is not proper C++.

My impression is that you want to keep an union of pointers because in certain circumstances you need an instance of a (sub)class of B, and in another an instance of C, with the issue of B and C having not quite the same interface. Perhaps you store several of these in a container, or simply you don't know until runtime which instance will be used.

So you may keep your code as it was, with perhaps a type tag somewhere indicating which instance has been created, and then use a switch each time you need to determine the correct code to run, or you could leverage your classes to actually invoke the proper function at run time, by including in the common base class of B and C⁽¹⁾ a virtual method, and overload this method in B and C with the proper branch of the switch, then replace the union with a simple pointer to the base class.

---

_{(1) that base class doesn't have to be A: if you don't want to clutter your class tree, just make a different class having the minimal interface needed there, and thanks to C++ multiple inheritance, have B and C inherit from it as well. Don't forget the virtual destructor!}

Answer 4

For me this case looks legit and there is no undefined behaviour.

1. He is using type-punning and it is legit because it B* b and C* c in union members is a pointers and could be converted to char array.
2. Both B and C have virtual destructor because of base class (not because base is a same! but because base have virtual destructor).

   12.4.9 If a class has a base class with a virtual destructor, its destructor (whether user- or implicitly-declared) is virtual.

3. While destructor call, (because it is virtual) exact function address will be picked up from choice variable and proper destructor sequence will be called. So there is no ANY undefined behaviour at all.