views:

72

answers:

1

Maybe even better is: Why does the standard require forwarding to a base class in these situations? (yeah yeah yeah - Why? - Because.)

class B1 {
public:
    virtual void f()=0;
};
class B2 {
public:
    virtual void f(){}
};
class D : public B1,public B2{
};
class D2 : public B1,public B2{
public:
    using B2::f;
};
class D3 : public B1,public B2{
public:
    void f(){
        B2::f();
    }
};
D d;
D2 d2;
D3 d3;

MS gives:

sourceFile.cpp
sourceFile.cpp(24) : error C2259: 'D' : cannot instantiate abstract class
        due to following members:
        'void B1::f(void)' : is abstract
        sourceFile.cpp(6) : see declaration of 'B1::f'
sourceFile.cpp(25) : error C2259: 'D2' : cannot instantiate abstract class
        due to following members:
        'void B1::f(void)' : is abstract
        sourceFile.cpp(6) : see declaration of 'B

and similarly for the MS compiler.

I might buy the first case,D. But in D2 - f is unambiguously defined by the using declaration, why is that not enough for the compiler to be required to fill out the vtable?

Where in the standard is this situation defined?

added in reponse to answer

Regarding the answer below that I have accepted:

Why does this not seem an error in the spec? - If one has an inheritance hierarchy with a series of non virtual f()'s, the use of which in derived classes being determined by using statements, and one changes the decl of f in a base class to virtual then that can change which f is called in derived classes with using statements to pick their f. It is a c++ "gotcha"of which I was unaware. It may be part of the language but such "action at a distance" makes me uneasy and to me seems a violation of some sort of correctness / maintenance principle (that I can't quite formulate right now).

But I can give an example:

#include <iostream>
using std::cout;


namespace NonVirtual_f{

class C0 {
public:
    void f(){cout<<"C0::f()"<<'\n';}
};

class C1 : public C0{
public:
    void f(){cout<<"C1::f()"<<'\n';}
};

class C2 : public virtual C1{
public:
    void f(){cout<<"C2::f()"<<'\n';}
};

class D3 : public virtual C1, public C2{
public:
    using C1::f;
};


}//namespace NonVirtual_f

namespace Virtual_f{


class C0 {
public:
    virtual void f(){cout<<"C0::f()"<<'\n';}
};

class C1 : public C0{
public:
    void f(){cout<<"C1::f()"<<'\n';}
};

class C2 : public virtual C1{
public:
    void f(){cout<<"C2::f()"<<'\n';}
};

class D3 : public virtual C1, public C2{
public:
    using C1::f;
};



}//namespace Virtual_f




int main(int argc,const char* const*argv){

    NonVirtual_f::D3 nv3;
    nv3.f();

    Virtual_f::D3 v3;
    v3.f();

    return 0;    
} 

Whence the output:

C1::f()
C2::f()

All that is changed is the virtualness of f in C0. In particular once the non-virtualness of f in a base class is chosen, it cannot be changed without maintenance issues if some derived class (that in general one can't know about) has "overridden" as in the example immediately above.

If you counter with "Well, do not override that way in the NonVirtual case", I agree it is bad practice but this seems more than just that. To me the language should:

not allow the using in NonVirtual::D3 (not possible currently as there may be other overloaded f's to bring in [unless using allowed a signature in the function case])

or

disallow using statements of functions completely and force forwarding

or

have using actually override in all cases

or

allow some syntactical declarative for functions (essentially a function using) like:

void f(*signature*) = C2::f;

What, exactly, am I missing here? Can someone come up with a scenario that clarifies the "why" of this choice in the standard?

+3  A: 

The C++ standard says in §10.3/2:

The rules for member lookup (10.2) are used to determine the final overrider for a virtual function in the scope of a derived class but ignoring names introduced by using-declarations.

So, even though you use using B2::f; to bring B2::f() into the derived class, it is not considered to override B1::f().

Thus, D2 is abstract because of §10.4/4:

A class is abstract if it contains or inherits at least one pure virtual function for which the final overrider is pure virtual.

James McNellis
Short and to the point. +1, more if I could.
Nikolai N Fetissov
And why does this not seem an error in the spec? - If one has an inheritance hierarchy with a series of non virtual f()'s, the use of which in derived classes being determined by using statements, and one changes the decl of f in a base class to virtual then that can change which f is called in derived classes with using statements to pick their f. It is a c++ "gotcha"of which I was unaware. It may be part of the language but such "action at a distance" makes me uneasy and to me seems a violation of some sort of correctness/maintenance principle (that I can't quite formulate right now)
pgast