Container covariance in C++

Question

I know that C++ doesn\'t support covariance for containers elements, as in Java or C#. So the following code probably is undefined behavior:

#include 

        

Answer 1

You are invoking the bad spirit of reinterpret_cast<>.

Unless you really know what you do (I mean not proudly and not pedantically) reinterpret_cast is one of the gates of evil.

The only safe use I know of is managing classes and structures between C++ and C functions calls. There maybe some others however.

Answer 2

I think it'll be easier to show than tell:

struct A { int a; };

struct Stranger { int a; };

struct B: Stranger, A {};

int main(int argc, char* argv[])
{
  B someObject;
  B* b = &someObject;

  A* correct = b;
  A* incorrect = reinterpret_cast<A*>(b);

  assert(correct != incorrect); // troubling, isn't it ?

  return 0;
}

The (specific) issue showed here is that when doing a "proper" conversion, the compiler adds some pointer ajdustement depending on the memory layout of the objects. On a reinterpret_cast, no adjustement is performed.

I suppose you'll understand why the use of reinterpet_cast should normally be banned from the code...

Answer 3

The general problem with covariance in containers is the following:

Let's say your cast would work and be legal (it isn't but let's assume it is for the following example):

#include <vector>
struct A {};
struct B : A { public: int Method(int x, int z); };
struct C : A { public: bool Method(char y); };
std::vector<B*> test;
std::vector<A*>* foo = reinterpret_cast<std::vector<A*>*>(&test);
foo->push_back(new C);
test[0]->Method(7, 99); // What should happen here???

So you have also reinterpret-casted a C* to a B*...

Actually I don't know how .NET and Java manage this (I think they throw an exception when trying to insert a C).

Answer 4

The rule violated here is documented in C++03 3.10/15 [basic.lval], which specifies what is referred to informally as the "strict aliasing rule"

If a program attempts to access the stored value of an object through an lvalue of other than one of the following types the behavior is undefined:

• the dynamic type of the object,

• a cv-qualified version of the dynamic type of the object,

• a type that is the signed or unsigned type corresponding to the dynamic type of the object,

• a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of the object,

• an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union),

• a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,

• a char or unsigned char type.

In short, given an object, you are only allowed to access that object via an expression that has one of the types in the list. For a class-type object that has no base classes, like std::vector<T>, basically you are limited to the types named in the first, second, and last bullets.

std::vector<Base*> and std::vector<Derived*> are entirely unrelated types and you can't use an object of type std::vector<Base*> as if it were a std::vector<Derived*>. The compiler could do all sorts of things if you violate this rule, including:

• perform different optimizations on one than on the other, or

• lay out the internal members of one differently, or

• perform optimizations assuming that a std::vector<Base*>* can never refer to the same object as a std::vector<Derived*>*

• use runtime checks to ensure that you aren't violating the strict aliasing rule

[It might also do none of these things and it might "work," but there's no guarantee that it will "work" and if you change compilers or compiler versions or compilation settings, it might all stop "working." I use the scare-quotes for a reason here. :-)]

Even if you just had a Base*[N] you could not use that array as if it were a Derived*[N] (though in that case, the use would probably be safer, where "safer" means "still undefined but less likely to get you into trouble).