What does C4250 VC++ warning mean?

Question

What does C4250 Visual C+ warning mean in practical terms? I've read the linked MSDN page, but I still don't get what the problem is.

What does the compiler warn me about and what problems could arise if I ignore the warning?

Answer 1

It means that the compiler has noticed that you are using a lesser known feature of virtual inheritance that it has a name for. I've no idea why they thought it was a good idea to make it a warning but it has no practical significance; the code should work as the language specifies, it's not pointing out a compiler deficiency or anything.

Answer 2

In the linked example you have diamond which inherits both weak and dominant, which both inherit virtually from vbc, but only dominant overrides func()

There is a problem in C++ when you have such a structure when you don't use virtual inheritance. However, with virtual inheritance, the problem is solved, so the warning is just information telling you that if:

1. You hadn't used virtual inheritance, OR
2. weak had implemented func()

then you would get a compiler error.

So, my opinion is that if you know what you are doing you can safely disable this warning for the whole of your project.

Answer 3

The warning is pointing out that if any weak class operations depend on vbc virtual operations that are implemented in dominant, then those operations might change behavior due to the fact that they are bundled in a diamond inheritance hierarchy.

struct base {
   virtual int number() { return 0; } 
};
struct weak : public virtual base {
   void print() { // seems to only depend on base, but depends on dominant
      std::cout << number() << std::endl;
   }
};
struct dominant : public virtual base {
   int number() { return 5; }
};
struct derived : public weak, public dominant {}

int main() {
   weak w; w.print();    // 0
   derived d; d.print(); // 5
}

That is the behavior that the standard specifies, but it might be surprising for the programmer at times, the weak::print operation behavior has changed not because of an overridden method above or below in the hierarchy, but by a sibling class in the inheritance hierarchy, when called from derived. Note that it makes perfect sense from the derived point of view, it is calling an operation that depends on a virtual method implemented in dominant.