1

Am I missing something, or did I find a Visual Studio bug?

Bugs aside, is using this type of inheritance OK or evil?

GCC 4.9.0 produces my expected results:

base.getProperty() 1
otherBase.getProperty() 2
derivedA.getProperty() 1
derivedB.getProperty() 2

But, both VS 2015 (CTP 6) and VS 2013 (Update 5 CTP) produce what I believe are incorrect results:

base.getProperty() 1
otherBase.getProperty() 2
derivedA.getProperty() 1
derivedB.getProperty() 1

Changing "class derivedClassB : public derivedClassA, otherBaseClass {" to "class derivedClassB : public otherBaseClass, derivedClassA {" produces my expected results. I could be missing something, but although the order of classes inherited from would affect initialization order, I don't think it is supposed to affect which ambiguous function to use -- especially when there is a using statement to clarify the otherwise present ambiguity.

#include <iostream>
using namespace std;

class baseClass {
public:
    virtual int getProperty() {
        return 1;
    }
};

class otherBaseClass : public baseClass {
public:
    virtual int getProperty() {
        return 2;
    }
};

class derivedClassA : public baseClass {
public:
    void someUniqueThing() {
        cout << "someUniqueThing" << endl;
    }
};

class derivedClassB : public derivedClassA, otherBaseClass {
public:
    using otherBaseClass::getProperty;
};

int main() {
    baseClass base;
    cout << "base.getProperty() " << base.getProperty() << endl;
    otherBaseClass otherBase;
    cout << "otherBase.getProperty() " << otherBase.getProperty() << endl;
    derivedClassA derivedA;
    cout << "derivedA.getProperty() " << derivedA.getProperty() << endl;
    derivedClassB derivedB;
    cout << "derivedB.getProperty() " << derivedB.getProperty() << endl;
}
user1902689
  • 1,655
  • 2
  • 22
  • 33
  • GCC is correct AFAIK. – chris Apr 29 '15 at 04:54
  • Just as the message said, due to the order of the multiple inheritance, `derivedClassA::getProperty` hides `otherBaseClass::getProperty` despite the `using` statement in `derivedClassB`. This should be a standard-compliance issue rather than a bug. – Lingxi Apr 29 '15 at 05:07

0 Answers0