Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
Assume a std::vector<Base*>, and a set of classes Derived1,..., DerivedN.
What is the correct/best architecture to decide on runtime to which of the Derived* classes I should dynamic_cast to?
Example:
I have the following classes: Cat,Dog,Horse,etc. They all have a Base class Animal.
I have a function to create an instance(s) of each of the derived classes, and I want to save the pointers somewhere, e.g. Bases* ptrs2derivedclesses.
Is there's a better way to save all the derived classes instances?
What is the correct/best architecture to decide on runtime to which of the Derived* classes I should dynamic_cast to?
Correct/best approach is to design proper interface of the base class using (pure) virtual functions. Dynamic/static cast is usable sometimes in special cases but in general it is a sign of a bad design.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
These recommendations boost::pointer_container suggest that one derives ABCs from boost::noncopyable to prevent slicing further down the hierarchy. Apart from the mentioned advantages, are there reasons why I should not follow this recommendation?
There is a thing called "empty base optimization" that will prevent derived class from growing when deriving from base class that has no non-static data members and no virtual functions (that is no vtable). MS Visual C++ however implements such optimization only for first base class (that is minimal standard requirement if I remember correctly). So if you want to derive your class from two empty base classes you'll waste empy base optimization on the ::boost::noncopyable. So it would be better to explicitly write deleted constructors / assignment operators in this case.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have a event based communication system, and this is the simplifed version of it:
class A: contains elements derived from class B
class B: has a pointer to its owner A
So when a B wants to communicate with other B-s, it calls A's Broadcast() method:
m_owner->Broadcast();
But I was wondering:
Should I make a protected Broadcast() method for B, which is just this:
m_owner->Broadcast();
Pros:
Instead of m_owner->Broadcast() I can write just Broadcast()
this makes the code cleaner.
Cons:
There will be +1 function calling in the procedure.
But this can be avoided by making the method inline
Is this a good practice? Why yes and why not?
In a situation that you have described, it probably indeed does not make much difference.
But in future you may find that you will need to add extra code to each place where Broadcast is called, for example logging or mutex locking. In this case, a separate function will be really useful.
Also you mention that you have classes derived from B. If this is a derived class that calls m_owner->Broadcast(), and m_owner is a base class field, then this is not a good pattern. Derived classes should better access parent's protected functions, not directly data members.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
Please provide a simple solution to restrict inheritance in C++.
Yes! As of C++11, there's a final specifier you can use to indicate that a class cannot be inherited from:
class DontInheritMe final {
// This class cannot be inherited from.
};
If you have experience in Java, the final keyword in C++ in this case works the same was as final classes in Java.
If u really dont want to inherit a class,then just make its member variables and member functions as private ,if other class tries to inherit it they cant have access to its funtions and variables anyways.
But using final is a better option
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Should I always add public keyword when inheriting a class? When doing this code:
class Derived : public Base {
}
I think this the right thing to do in 99% cases. Right?
It depends on what model you are looking for.
From Scott Myers - Effective C++ Third Edition (a recommended read, btw):
public inheritance means "is-a". If you write that class D ("Derived") publicly inherits from class B ("Base"), you are telling C++ compilers (as well as human readers of your code) that every object of type D is also an object of type B, but not vice versa
And
private inheritance means "is-implemented-in-terms-of"
Yes, because this matches the inheritance behavior of other object oriented programming languages like C# or Java.
If you would use private instead of public, the properties and methods of the Base class are hidden. This means that the compiler would not allow you to call public methods of the Base class if you have a pointer of the Derived class.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I found this question: When to use abstract class or interface?. But it was asked for Java and C++ is different. There is multiple inheritence so maybe the answers are different too.
When shall I use an interface class ?
If I use the PIMPL idiom then there will be only one member which I only need to forward declare. And if I move the private functions into the PIMPL class then there will be only public and protected functions in a abstract class. So the difference between an abstract class like this and an ˙interface class is that in the interface class there shall be only pure virtual functions. Does it have any advantages over the previously mentioned one ?
Use an interface class when the class hierarchy can be viewed as generic; child classes can be swapped without affecting the calling classes.
For example, there is an std::istream class. Any function or method can treat input as generic if it requires an std::istream. So, one can pass cin or an ifstream to the function. The interface is consistent.
Use the PIMPL idiom when you want to hide the implementation from the interface. Used in library classes.