Static code analysis tools tend to ramble a lot about "downcasting a base class to a derived class" and I also found a couple of coding standard guides, which mention not to do this so I was wondering what is the best-practice way.
Here's my use case:
I have a Base (interface), DerivedA, DerivedB classes and then an array containing Base pointers.
Then I iterate through the array and based on a flag, I determine if the object is DerivedA or DerivedB, cast it down and do some random stuff to the object from the outside.
Basically something like this:
// arr is of type Base**
for (int i = 0; i < size; ++i)
{
// doMagic has an overload for both types
if (arr[i]->isDerivedA())
{
doMagic(reinterpret_cast<DerivedA*>(arr[i]));
}
else if (arr[i]->isDerivedB())
{
doMagic(reinterpret_cast<DerivedB*>(arr[i]));
}
}
Bout the reinterpret, I cannot use dynamic_cast due to embedded platform restrictions (the same for C++11), but the Base class being an interface guarantees that the object is either DerivedA or DerivedB.
I could make DerivedA and DerivedB only implement pure virtual calls, thus i wouldn't have to worry about downcasting anything, but the DerivedA and DerivedB classes are very much specialized and doMagic does completely different things with the instances...
So I was wondering how you guys approach this - having a single array of very different objects, but inherited from a single base, iterating through them and doing some specialized stuff from the outside.
You probably should try to use visitor pattern.
Here is a simple example:
#include <cstdio>
class A;
class B;
class Visitor {
public:
void visit(A &a) {
printf("Visited A\n");
}
void visit(B &) {
printf("Visited B\n");
}
};
class A {
public:
virtual ~A() { }
virtual void applyVisitor(Visitor &v) {
v.visit(*this);
}
};
class B : public A {
public:
~B() override { }
void applyVisitor(Visitor &v) override {
v.visit(*this);
}
};
int main() {
A a;
B b;
Visitor v;
a.applyVisitor(v);
b.applyVisitor(v);
return 0;
}
If you know that a pointer of a base class points to an object of a derived class, you may use static_cast. The compiler will insert appropriate code to adjust offsets, unlike reinterpret_cast or a C-Cast.
Related
late-binding or runtime-polymorphism needs 2 things: a base pointer and a virtual method.
class FrameWorkClassBase {
public:
virtual void method() = 0;
};
class FrameWorkClassDerived: public FrameWorkClassBase {
public:
virtual void method() override { ... }
}
class ProductionConsumerClass { // uses composition
public:
void method() {
this->m_sptr->method(); // dynamic dispatch
}
private:
// ptr to base class, composition at work
std::shared_ptr<FrameWorkClassBase> m_sptr =
std::make_shared<FrameWorkClassDerived>();
}
there seems to be a bias towards using heap memory for polymorphic object creation rather than stack allocated objects, especially when it comes to using "polymorphic object" as component objects. Is this a requirement: is it the nature of the C++ language as a whole that forces the use of heap memory for "polymorphic component objects" ? Are there any design patterns that overcome the need for using heap memory for "polymorphic component objects" ?
Note: I do not want to use base class l-value reference(FrameWorkClassBase&) as a data member in ProductionConsumerClass as i do not have life-time-guarantee/ownership of the referred object.
There is no need to use heap allocation for late binding to work:
#include <iostream>
struct Base {
virtual void print() { std::cout << "Base\n"; }
};
struct Derived : public Base {
void print() override { std::cout << "Derived\n"; }
};
struct Composed {
Base b;
Derived d;
};
int main() {
Base b;
Derived d;
Composed c;
Base &bb{b}, &bd{d}, &cbb{c.b}, &cbd{c.d};
bb.print(); // Base
bd.print(); // Derived
cbb.print(); // Base
cbd.print(); // Derived
}
In the example above, no heap allocation takes place and all reference variables are of type Base&. Late binding works just fine.
Imagine following scenario. I derive from a library class to enable the visitor pattern:
#include <iostream>
#include <vector>
struct MyClassA;
struct MyClassB;
struct MyVisitor{
virtual void visit(MyClassA* c) { std::cout << "My Class A" << std::endl; }
virtual void visit(MyClassB* c) { std::cout << "My Class B" << std::endl; }
};
struct LibClass {};
struct MyClass : public LibClass {
virtual void Accept(MyVisitor& visitor) = 0;
};
struct MyClassA : public MyClass {
virtual void Accept(MyVisitor& visitor) {
visitor.visit(this);
}
};
struct MyClassB : public MyClass {
virtual void Accept(MyVisitor& visitor) {
visitor.visit(this);
}
};
// vector signature can't be changed
void foo(std::vector<LibClass*>& v) {
MyVisitor visitor;
for(auto libC : v) {
auto myC = static_cast<MyClass*>(libC); // questionable line
//auto myC = dynamic_cast<MyClass*>(libC); // don't want to use dynamic cast
myC->Accept(visitor);
}
}
int main() {
// vector signature can't be changed
std::vector<LibClass*> v;
v.push_back(new MyClassA());
v.push_back(new MyClassB());
foo(v);
return 0;
}
The output is as expected:
My Class A
My Class B
This is a question regarding design. In my eyes, it is bad style to use dynamic_cast and should be avoided. As the vector can get quite large, I also want to avoid calls on the iteration to dynamic_cast.
I can be sure, that every pointer in the vector is derived from MyClass.
I want to use the visitor pattern to implement features depending on the derived class, so I will implement derived classes of MyVisitor, too. MyVisitor later could be provide a virtual interface for all possible childrens. The concrete Visitors than can override only that methods, on which children they want to interact with.
So my questions are:
Is there any danger using the static_cast in that way?
Would you consider this a good design under the circumstance, that I want to insert the possibilty to use the visitor pattern?
dynamic_cast is safer (assuming checking for nullptr) as compiler might check at runtime that the class is really what you want. (No compile-time hierarchy check, due to possible multiple inheritance). foo can be used safely (Even by LibClass which are not MyClass).
With static_cast, you do a promise to the compiler. Breaking it would lead to UB.
The only check done at compile time is that derived class (MyClass) is actually in the hierarchy of the base class (LibClass).
foo signature is now misleading, as you expect only MyClass instead of any LibClass.
But as long as you don't break that promise, code is ok.
Suppose we want to implement strategy pattern. We have an interface Base and two derived classes -- A and B. Instances of Doer class can choose between A's and B's methods do(). And the question is how to complete the code to make how it should be.
class Base {
virtual void do() const = 0;
};
class A: public Base {
void do() const override {};
};
class B: public Base {
void do() const override {};
}
class Doer {
public:
Doer(std::unique_ptr<Base> b_ptr) : ptr(b_ptr) {}
void do() const { ptr->do(); }
private:
std::unique_ptr<Base> ptr;
}
int main() {
Doer doer(std::unique_ptr<Base>());
doer.do();
return 0;
}
Doer doer(std::make_unique<A>()); // or std::make_unique<B>()
The above is pretty much it. std::unique_ptr works very hard to implement the same coercion as the raw pointer it holds.
There are three major problems with your code.
1) do is a keyword of the language. You cannot use it as an identifier (like function name)
2) you take b_ptr by value, so you need to move from it:
Doer(std::unique_ptr<Base> b_ptr) : ptr(std::move(b_ptr)) {}
3) you pass an empty unique_ptr to Doer's constructor, which is equivalent to passing a nullptr. You also try to instantiate the base class. It is impossible because Base is a pure virtual class. Use make_unique with a derived type:
Doer doer(std::make_unique<A>());
Not sure how to explain it well, so I will just provide a sample of code that shows my problem:
class Base {
public:
Base() = default;
~Base() = default;
virtual void stuff(std::shared_ptr<Base> b) = 0;
};
class DerivedA : public Base {
public:
DerivedA() = default;
~DerivedA() = default;
void stuff(std::shared_ptr<Base> b) {
std::cout << "stuff Base"
<< "\n";
}
};
class DerivedB : public Base {
public:
DerivedB() = default;
~DerivedB() = default;
void stuff(std::shared_ptr<Base> b) {
std::cout << "stuff Base"
<< "\n";
}
void stuff(std::shared_ptr<DerivedA> b) {
std::cout << "stuff Derived"
<< "\n";
}
};
int main(int argc, char *argv[]) {
std::shared_ptr<Base> b1(new DerivedA());
std::shared_ptr<Base> b2(new DerivedB());
b1->stuff(b2);
b2->stuff(b1);
return 0;
}
The output will be:
stuff Base
stuff Base
Now, I suppose it is not possible to call the derived method as it doesn't exist in the base class.
My question is: Is there a way to call stuff(std::shared_ptr<DerivedA> b) using the base class ?
[EDIT]
I already thought about the visitor pattern (should have said it and be more specific).
My classes represent Entities and I have to check collisions between them. However a collision between A & B will have a different effect than between B & C.
I agree that it will work, but it means that I will have to define tons of methods.
Is there a more elegant way to do it ?
Thanks in advance.
What you are looking for is commonly called multiple dispatch, or a multimethod. There is no direct language support for this in C++, but you can explicitly implement it yourself. Basically, you have one virtual function which dispatches to another virtual function with a concrete object:
struct DerivedA;
struct DerivedB;
struct Base {
virtual ~Base() = default;
virtual void stuff(shared_ptr<Base> ) = 0;
virtual void dispatch_stuff(Base& ) = 0;
virtual void dispatch_stuff(DerivedA& p) { return dispatch_stuff(static_cast<Base&>(p)); }
virtual void dispatch_stuff(DerivedB& p) { return dispatch_stuff(static_cast<Base&>(p)); }
struct DerivedA : Base {
void stuff(shared_ptr<Base> rhs) override {
rhs->dispatch_stuff(*this);
}
void dispatch_stuff(Base& ) { /* default */ }
void dispatch_stuff(DerivedA& ) { /* specific A-A stuff */ }
};
This way:
b1->stuff(b2); // calls b2->dispatch_stuff(DerivedA& )
b2->stuff(b1); // calls b1->dispatch_stuff(DerivedB& )
My question is: Is there a way to call
stuff(std::shared_ptr<DerivedA> b) using the base class ?
No, because the Base class interface doesn't implement the method you want to call. Even though the Base class pointer is referring to a DerivedB object, and through poilformism you can resolve the method with the respect to the type of the object pointed by the pointer (i.e. DerivedB), you can only call the method defined in the Base class. Therefore, you cannot call stuff(std::shared_ptr<DerivedA> b) using a Base pointer that points to a DerivedB object.
For example:
std::shared_ptr<Base> b1(new DerivedA());
std::shared_ptr<Base> b2(new DerivedB());
std::shared_ptr<DerivedA> a1(new DerivedA());
std::shared_ptr<DerivedB> bb1(new DerivedB());
b1->stuff(b2);
b2->stuff(b1);
b2->stuff(a1); // b2 is the only class that implement stuff(std::shared_ptr<DerivedA> b)
bb1->stuff(a1)
output:
stuff Base
stuff Base
stuff Base
stuff Derived
stuff Base
The problem you are trying to solve is called the double dispatch problem, which means you're trying to invoke a behaviour depending on the concrete type of two objects. Looking up this term on google or here may yield you some interesting results.
First thing, one way or another, you're going to have to write a lot of functions since if you have N different types there are NN possible pairings. (NN/2 if order doesn't matter, which is probably the case in your collision scenario).
The visitor pattern is one of the canonical solutions to the double dispatch problem.
There are others, depending on what matters to you. Off the top of my head, for example, if the number of subtypes is limited and known at compile time, you can for example have an index for each type and a 2D array of function pointers to call (not very elegant nor very object oriented but quite efficient in terms of performance).
If you fear that the number of functions is likely to cause code duplication you can always factor the code inside a function, or a class ( something like CollisionPairBehavior ).
I've got a base class that has a virtual function. I want to call that class during the construction because I want the function called for each of the derived classes. I know I can't call a virtual function during construction, but I can't think of an elegant (i.e., avoid repeating code) solution.
What are some work arounds to calling a virtual function during construction?
The reason I want to avoid this is because I don't want to have to create constructors that just call the base class.
class A {
public:
A() {
read();
}
// This never needs to be called
virtual void read() = 0;
}
class B:A {
public:
B():A() { };
read() { /*Do something special for B here.*/ }
}
class C:A {
public:
C():A() { };
read() { /*Do something special for C here.*/ }
}
PS: The Python way of doing this is simply to raise NotImplementedError in A::read(). I'm returning to C++ and I'm more rusty than I thought.
The FAQ perspective.
This is a Frequently Asked Question.
See the C++ FAQ item titled “Okay, but is there a way to simulate that behavior as if dynamic binding worked on the this object within my base class's constructor?”.
It’s very often a good idea to check the FAQ (and generally, googling or altavista’ing) before asking.
The question as “Derived class specific base initialization”.
To be clear, while the literal question above is
“What are some work arounds to calling a virtual function during construction?”
it is evident that what’s meant is
“How can a base class B be designed so that each derived class can specify part of what goes on during B construction?”
A major example is where C style GUI functionality is wrapped by C++ classes. Then a general Widget constructor might need to instantiate an API-level widget which, depending on the most derived class, should be a button widget or a listbox widget or whatever. So the most derived class must somehow influence what goes on up in Widget’s constructor.
In other words, we’re talking about derived class specific base construction.
Marshall Cline called that “Dynamic Binding During Construction”, and it’s problematic in C++ because in C++ the dynamic type of an object during class T construction and destruction, is T. This helps with type safety, in that a virtual member function is not called on a derived class sub-object before that sub-object has been initialized, or its initialization has started. But a major cost is that DBDI (apparently) can’t be done in a way that is both simple and safe.
Where the derived class specific init can be performed.
In the question the derived class specific action is called read. Here I call it derived_action. There are 3 main possibilities for where the derived_action is invoked:
Invoked by instantiation code, called two-phase construction.
This essentially implies the possibility of having a mostly unusuable not fully initialized object at hand, a zombie object. However, with C++11 move semantics that has become more common and accepted (and anyway it can be mitigated to some extent by using factories). A main problem is that during the second phase of construction the ordinary C++ protection against virtual calls on uninitialized sub-objects, due to dynamic type changes during construction, is not present.
Invoked by Derived constructor.
For example, derived_action can be invoked as an argument expression for the Base constructor. A not totally uncommon technique is to use a class template to generate most derived classes that e.g. supply calls of derived_action.
Invoked by Base constructor.
This implies that knowledge of derived_action must be passed up to the constructor, dynamically or statically. A nice way is to use a defaulted constructor argument. This leads to the notion of a parallel class hierarchy, a hierarchy of derived class actions.
This list is in order of increasing sophistication and type safety, and also, to the best of my knowledge, reflects the historical use of the various techniques.
E.g. in Microsoft’s MFC and Borland’s ObjectWindows GUI early 1990’ libraries two-phase construction was common, and that kind of design is now, as of 2014, regarded as very ungood.
This is the factory method approach, putting the factory into the base class:
class A {
public:
virtual void read() = 0;
template<class X> static X* create() {X* r = new X;X->read();return X;}
virtual A* clone() const = 0;
};
class B : public A {
B():A() { };
friend class A;
public:
void read() { /*Do something special for B here.*/ }
B* clone() const {return new B(*this);}
};
class C : public A {
C():A() { };
friend class A;
public:
void read() { /*Do something special for C here.*/ }
C* clone() const {return new C(*this);}
};
Added a clone-method with covariant return type as a bonus.
Using CRTP:
class A {
public:
// This never needs to be called
virtual void read() = 0;
virtual A* clone() const = 0;
};
template<class D, class B> struct CRTP : B {
D* clone() {return new D(*this);}
static D* create() {return new D();}
};
class B : public CRTP<B, A> {
B() { };
public:
void read() { /*Do something special for B here.*/ }
};
class C : public CRTP<C, A> {
C() { };
public:
void read() { /*Do something special for C here.*/ }
};
One way to achieve this, would be simply to delegate it to another class (that is perhaps a friend) and can be sure to be called when fully constructed.
class A
{
friend class C;
private:
C& _c; // this is the actual class!
public:
A(C& c) : _c(c) { };
virtual ~A() { };
virtual void read() = 0;
};
class B : public A
{
public:
B(C& c) : A(c) { };
virtual ~B() { };
virtual void read() {
// actual implementation
};
};
class C
{
private:
std::unique_ptr<A> _a;
public:
C() : _a(new B(*this)) { // looks dangerous? not at this point...
_a->read(); // safe now
};
};
In this example, I just create a B, but how you do that can depend on what you want to achieve and use templates on C if necessary, e.g:
template<typename VIRTUAL>
class C
{
private:
using Ptr = std::unique_ptr<VIRTUAL>;
Ptr _ptr;
public:
C() : _ptr(new VIRTUAL(*this)) {
_ptr->read();
};
}; // eo class C
The workaround is to call the virtual function after construction. You can then couple the two operations (construction + virtual call) in factory function. Here is the basic idea:
class FactoryA
{
public:
A *MakeA() const
{
A *ptr = CreateA();
ptr->read();
return ptr;
}
virtual ~FactoryA() {}
private:
virtual A *CreateA() const = 0;
};
class FactoryB : public FactoryA
{
private:
virtual A *CreateA() const { return new B; }
};
// client code:
void f(FactoryA &factory)
{
A *ptr = factory.MakeA();
}
As mentioned by Benjamin Bannier, you can use CRTP (a template which defines the actual read() function.) One problem with that method is that templates have to always be written inline. That can at times be problematic, especially if you are to write really large functions.
Another way is to pass a function pointer to the constructor. Although, in a way, it is similar to calling the function in your constructor, it forces you to pass a pointer (although in C++ you could always pass nullptr.)
class A
{
public:
A(func_t f)
{
// if(!f) throw ...;
(*f)();
}
};
class B : A
{
public:
B() : A(read) {}
void read() { ... }
};
Obviously, you have the "can't call other virtual functions" problem within the read() function and any function it calls. Plus, variable members of B are NOT yet initialized. That is probably a much worst problem in this case...
For that reason, writing it this way is safer:
B() : A()
{
read();
}
However, in cases like that, that may be the time when you an some for of init() function. That init() function can be implemented in A() (if you make it accessible: i.e. use public A when deriving) and that function can call all the virtual functions as expected:
class A
{
public:
void init()
{
read();
}
};
class B : public A
{
public:
...
};
I know a lot of people say that an init() function is evil because people who create a B object now need to know to call it... but there isn't much else you can do. That being said, you could have a form of factory, and that factory can do the init() call as required.
class B : public A
{
public:
static B *create() { B *b(new B); b->init(); return b; }
private:
B() { ... } // prevent creation without calling create()
};