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.
Related
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.
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 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.
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
sorry to bother but I'm a newbie programmer and has just been starting on c++ course. The reason I asked this question is because I've been hearing on OOP and its relation to class.
So my question is:
Does class actually simplify the programming code just because it groups up all related functions into one single "object" thats called "class" ?
One more thing is that...
Why do we create class inheritance when we could use one class and derive all functions from that one class alone?
Sorry to bother.
Newbie programmer.
"Does class actually simplify the programming code just because it groups up all related functions into one single "object" thats called "class" ?"
The main idea is to encapsulate state (== data) with operations that can be applied to it into a single class type.
Yes, that simplifies programming code, because there are certain interfaces/operations that can be used with this type.
"Why do we create class inheritance when we could use one class and derive all functions from that one class alone?"
Derived classes may introduce different behavior as inherited from their base class. There are many uses when you want to change that behavior, without inventing new function names all the time (or just add numbers to them).