I have a class A that was inherited from class B. So the interface of class A contains some pure virtual functions of class B and some functions of class A. Now I need to make unit tests for class A, so wanna have some interface for class A that I can mock.
So now I'm wondering if the given code is correct in C++14 and can it lead to UB:
class Base1 {
public:
virtual void func() = 0;
};
class Base2 {
public:
virtual void func() = 0;
};
class Derived : public Base1, public Base2 {
public:
void func() override { }
};
int main() {
Derived d;
d.func();
return 0;
}
Yes, this code is well-formed and void func() overrides both A::func() and B::func(). From the C++14 standard:
[class.virtual]
If a virtual member function vf is declared in a
class Base and in a class Derived, derived directly or indirectly
from Base, a member function vf with the same name,
parameter-type-list (8.3.5), cv-qualification, and ref-qualifier (or
absence of same) as Base::vf is declared, then Derived::vf is also
virtual (whether or not it is so declared) and it overrides
Base::vf.
Related
I'd appreciate if anyone could enlighten me what is going on here: Say I declare the following
class Base {
public:
virtual void member(Base b) = 0;
};
which give the following compiler error:
pvf.cpp:3:18: error: cannot declare parameter ‘b’ to be of abstract type ‘Base’
virtual void member(Base b) = 0;
^
pvf.cpp:1:7: note: because the following virtual functions are pure within ‘Base’:
class Base {
^
pvf.cpp:3:18: note: virtual void Base::member(Base)
virtual void member(Base b) = 0;
However, if I pass by reference, it compiles without problems:
class Base {
public:
virtual void member(Base& b) = 0;
};
Furthermore, I'd like to implement member() in the derived class as
class Base {
public:
virtual void member(Base& b) = 0;
};
class Derived : public Base {
public:
void member(Derived& d) {};
};
int main() {
Derived d;
}
However, (obviously?) I get
pvf.cpp: In function ‘int main()’:
pvf.cpp:12:14: error: cannot declare variable ‘d’ to be of abstract type ‘Derived’
Derived d;
^
pvf.cpp:6:8: note: because the following virtual functions are pure within ‘Derived’:
class Derived : public Base {
^
pvf.cpp:3:15: note: virtual void Base::member(Base&)
virtual void member(Base& b) = 0;
Your first function
virtual void member(Base b) = 0;
takes a parameter of class Base by value which requires an instance of Base to be passed to it. But as Base is an abstract class (because it contains a pure virtual function) it cannot be instantiated and therefore you cannot create an instance of Base to pass to it! That is the reason for your first error.
In your second case, in your derived class you declare a function
void member(Derived& d) {};
which you may think overrides the base class virtual function
virtual void member(Base& b) = 0;
but it does not (it in fact, hides it - see Why does a virtual function get hidden? for an explanation of this), and so Derived remains abstract class because you have not provided an implementation of the pure virtual function in the base class. For this reason Derived also cannot be instantiated. Derived classes that fail to provide an implementation for a base class pure virtual function will remain abstract just like the base class.
The code below surprisingly compiles in VS 2012.
Method C::f() overrides methods in both base classes.
Is this standard behavior? I looked into C++11 standard, and didn't find any explicit mentioning of such situation.
class A { virtual void f() = 0; };
class B { virtual void f() = 0; };
class C : public A, public B {
virtual void f() override { }
};
Yes. The standard says, in C++11 10.3/2
If a virtual member function vf is declared in a class Base and in a class Derived, derived directly or indirectly from Base, a member function vf with the same name [etc.] as Base::vf is declared, then [...] it overrides Base::vf.
There are no special cases for multiple base classes, so a function declared in the derived class will override a suitable function in all base classes.
Herb Sutter explains how to deal with this here.
According to the article:
class B1 {
public:
virtual int ReadBuf( const char* );
// ...
};
class B2 {
public:
virtual int ReadBuf( const char* );
// ...
};
class D : public B1, public B2 {
public:
int ReadBuf( const char* ); // overrides both B1::ReadBuf and B2::ReadBuf
};
This overrides BOTH functions with the same implementation
The following example is from the book "Inside C++ object model"
class Abstract_base {
public:
virtual ~Abstract_base () = 0;
virtual void interface () const = 0;
virtual const char* mumble () const
{
return _mumble;
}
protected:
char *_mumble;
};
The author says if I want to initialize _mumble, the data member of the pure virtual base class, a "protected constructor" should be implemented.
But why protected? And why "public constructor" is not suitable for this class?
Thanks for your answers, and it would be perfect if there's an example.
It doesn't really matter, since you're not allowed to construct objects of the base class anyway. Making it protected serves only as a reminder of the fact that the class is supposed to be a base class; it's only cosmetics/documentation.
Consider
struct Base {
virtual ~Base() = 0;
protected:
Base() { std::puts("Base constructor"); }
};
Base::~Base() { std::puts("Base destructor"); }
struct Derived : Base {};
int main()
{
//Base b; // compiler error
Derived d;
Base *b = new Derived();
delete b;
}
Removing the protected doesn't change the meaning of the program in any way.
Abstract classes and construction of such
It doesn't matter if the constructor is public or protected, since an abstract class cannot be instantiated.
You must inherit from it in order to have it's constructor called, and since the Derived class calls the constructor of the abstract class it doesn't matter what protection level you choose, as long as the Derived class can access it.
One reason that one could possibly have for making it protected is to serve as a reminder that the class must be constructed through inheritance, but honestly that should be clear enough when seeing that it has pure virtual member-functions.
example snippet
struct B {
virtual void func () = 0;
virtual ~B () = 0 { };
};
B::~B () { }
struct D : B {
void func () override;
};
int main () {
B b; // will error, no matter if Bs ctor is 'public' or 'protected'
// due to pure virtual member-function
D d; // legal, D has overriden `void B::func ()`
}
A pure virtual class cannot be instantiated, so it doesn't make a difference if the constructor is public or protected.
A public constructor is syntactically correct. However, making it protected will carry a stronger indication that the class cannot be instantiated.
For an example: http://ideone.com/L66Prq
#include <iostream>
using namespace std;
class PublicAbstract {
public:
PublicAbstract() { }
virtual void doThings() =0;
};
class ProtectedAbstract {
protected:
ProtectedAbstract() { }
public:
virtual void doMoreThings() =0;
};
class B: public PublicAbstract {
public:
void doThings() { }
};
class C: public ProtectedAbstract {
public:
void doMoreThings() { }
};
int main() {
B b;
C c;
return 0;
}
A public constructor would not be very useful, since abstract classes cannot be instantiated in the first place.
A protected constructor makes sense: this way, a derived concrete class can provide its own public constructor that chains to the protected constructor of the base abstract class.
Protecetd ctor will make sure the ctor gets called by only the classes which derive from Abstract_base.
Public ctor is not suitable because the class contains a pure virtual method! How are you planning to instantiate a pure-virtual class if not via its child classes?
I have the header file "testcode.h"
#ifndef TESTCODE_H
#define TESTCODE_H
class A
{
public:
A();
~A();
virtual void Foo();
public:
int mPublic;
protected:
int mProtected;
private:
int mPrivate;
};
class B : public A
{
public:
B();
~B();
void Foo();
};
#endif // TESTCODE_H
and a source file
#include "TestCode.h"
int main(int argc, char* argv[])
{
A* b = new B();
b->Foo();
b->mPublic = 0;
b->mProtected = 0;
b->mPrivate = 0;
delete b;
return 0;
}
Here, i would like to know that when I am calling "b->Foo", the Foo function of the class B is called instead of class A. However, the Foo function of class B is not declared as virtual. Can anyone elaborate on this ??
Once a function is declared virtual in a base class, it doesn't matter if the virtual keyword is used in the derived class's function. It will always be virtual in derived classes (whether or not it is so declared).
From the C++11 standard, 10.3.2:
If a virtual member function vf is declared in a class Base and in a
class Derived, derived directly or indirectly from Base, a member
function vf with the same name, parameter-type-list (8.3.5),
cv-qualification, and refqualifier (or absence of same) as Base::vf is
declared, then Derived::vf is also virtual (whether or not it is so
declared) and it overrides Base::vf. ...
B::Foo doesn't need to be declared as virtual--the fact that A::Foo is virtual and B derives from A means it's virtual (and overridden). Check out the msdn article on the virtual functions for more info.
In C++, let's say I have a class Derived that implements an interface class BaseInterface, where BaseInterface has only pure virtual functions and a virtual destructor:
class BaseInterface
{
public:
virtual void doSomething() = 0;
~BaseInterface(){}
};
class Derived : public BaseInterface
{
public:
Derived() {}
~Derived(){}
protected:
virtual void doSomething();
private:
int x;
};
No classes outside the Derived class hierarchy should call Derived::doSomething() directly, i.e., it should only be accessed polymorphically through the BaseInterface class. To enforce this rule, I have made Derived::doSomething() protected. This works well, but I'm looking for opinions pro/con regarding this approach.
Thanks!
Ken
I think you're looking for the non-virtual interface (NVI) pattern: a public non-virtual interface that calls a protected or private virtual implementation:
class BaseInterface
{
public:
virtual ~BaseInterface(){}
void doSomething() { doSomethingImpl(); }
protected:
virtual void doSomethingImpl() = 0;
};
class Derived : public BaseInterface
{
public:
Derived() {}
virtual ~Derived(){}
protected:
virtual void doSomethingImpl();
private:
int x;
};
If it is part of the interface, why would you not want users to call it? Note that as it is, they can call it: static_cast<BaseInterface&>(o).doSomething() is just an awkward way of saying o.doSomething(). What is the point of using the interface... if the object fulfills the interface, then you should be able to use it, or am I missing something?
Since you are not actually blocking anyone from calling the methods, I don't see a point in making the code more complex (both the class and users of the class) for no particular reason. Note that this is completely different from the Non-Virtual Interface in that in this idiom virtual functions are not accessible publicly (at any level) while in your case, the intention is allowing access, and making it cumbersome.
What you are doing is also mentioned in standard ISO/IEC 14882:2003(E) 11.6.1 and believe you are correct. Other than the fact, the member function isn't pure virtual in the given example. It should hold for pure virtual functions too, AFAIK.
The access rules (clause 11) for a virtual function are determined by its declaration and are not affected by the rules for a function that later overrides it.
[Example:
class B
{
public:
virtual int f();
};
class D : public B
{
private:
int f();
};
void f()
{
D d;
B* pb = &d;
D* pd = &d;
pb->f(); // OK: B::f() is public,
// D::f() is invoked
pd->f(); // error: D::f() is private
}
—end example]
Access is checked at the call point using the type of the expression used to denote the
object for which the member function is called (B* in the example above). The access of the member function in the class in which it was defined (D in the example above) is in general not known.
The key is the rest of your code. Only accept a BaseInterface* as an argument to any methods that require the doSomething() call. The client programmer is forced to derive from the interface to make his code compile.
This makes no sense to me. Regardless of which pointer you call doSomething(), you would still wind up with the method defined in most derived class. Consider the following scenario:
class BaseInterface
{
public:
virtual void doSomething() = 0;
~BaseInterface(){}
};
class Derived : public BaseInterface
{
public:
Derived() {}
~Derived(){}
virtual void doSomething(){}
private:
int x;
};
class SecondDerived : public Derived
{
public:
SecondDerived() {}
~SecondDerived(){}
private:
int x;
};
int main(int argc, char* argv[])
{
SecondDerived derived;
derived.doSomething(); //Derived::doSomething is called
BaseInterface* pInt = &derived;
pInt->doSomething(); //Derived::doSomething is called
return 0;
}