When should I implement inheritance using private or protected keywords (eg. class B : private A for example), preferably in game programming? I don''t know what this is called in english, so my apologies. My first completed game! Where''s that???

first of all you cant inherit in protected mode,

for private it treates all methods and variables in the base class as private, so you cant access them from the derived class, kind of useless if you ask me, well it probably has some use, but ive neveeer used it.

Sorry, I wasn''t paying attention. The word inheritance is wrong in this context.
I''ve seen stuff like this:
Class A
{
}
Class B : private A //could be also protected
{}

I believe this is called implementation inheritance. What''s it do?

My first completed game! Where''s that???

are you asking what inheritance is/ what it does?

According to the language specification you _can_ inherit in
protected mode. Stroustrup''s C++ Programming Language says the following about the different modes of inheritance:

Consider a class D derived from a base class B:
- If B is a private base, its public and protected members can
be used only by member functions and friends of D. Only
friends and members of D can convert a D* to a B*.
- If B is a protected base, its public and protected members can
be used only by member functions and friends of D and by
member functions and friends of classes derived from D. Only
friends and members of D and friends and members of classes
derived from D can convert a D* to a B*.
- If B is a public base, its public members can be used by any
function. In addition, its protected members can be used by
members and friends of D and members and friends of classes
derived from D. Any function can convert a D* to a B*.

Stroustrup also gives the following advice about the usage of the inheritance modes:

Public derivation makes the derived class a subtype of its base; this is the most common form of derivation. Protected and private derivation are used to represent implementation details. Protected bases are useful in class hierarchies in which further derivation is the norm. Private bases are most useful when defining a class by restricting the interface to a base so that stronger guarantees can be provided (for example creating a new vector class which adds range checking to the stdlib vector).

I''ve heard this:
use public when D is-a B (we all know this).
use private when D is-implemented-in-terms-of B. I''ve also heard you use private when D was-a B. I forget where, but the example was you have a Battleship class (not the game, an actual ship). So you can do all the things with this class that you can do with a battleship. So what if you want to make an ArizonaMemorial class?

(for those who don''t know, the Arizona was a ship that was sunk during the Pearl Harbor attack and settled on the floor of the harbor; there''s a memorial bridge over it, and you can see the ship straight underneath you through the water).

Obviously, ArizonaMemorial class is a battleship, but it can''t do all the things that battleships usually do because it isn''t afloat. So you''d use class ArizonaMemorial : private Battleship, and use public funnctions in the class that would perhaps call functions in Battleship.

I''ve never heard a good reason to use protected inheritence. Maybe the previous AP can give a concrete example?

Well, as you said private inheritance is useful when D is-implemented-in-terms of B. Now consider the situation where you want to implement D in terms of B and then implement C in terms of D simultaneously overriding some feature defined in B.

If you are using private inhertance to inherit D from B, then you can override the feature easily in D. But if you''d like to override it in C you can''t do it, as D inherited B privately and thus C doesn''t see it.

So inheriting protected is the way to go. If you inherit D from B protected, you can inherit C from D and override features defined in B.

--

Ok, a concrete example is probably useful here.

Lets assume you have a class called GameObject, from which you inherit all the objects in the game. The GameObject class contains a method that increases a given counter and is used to calculate the number of objects currently in use in the game.

For example GameObject::count(counter), which increases the given counter by one and is used in a loop that traverses all the game objects, calling count for each of them.

You inherit a class, lets say a man for example. So you define class Man which inherits from GameObject. As GameObject clearly is only an implementation detail, you want to inherit it private or protected.

Lets further assume that you inherit a class Commander from the class Man. Commander always has a unit containing at least himself, but usually more men.

You also define an invariant that the commander must always know how many men he has. Also the men are always linked to the commander and not to the public list of game objects, that is, the commander represents the whole unit in the game object list (maybe this is beneficial for efficiency reasons or something).

Now here''s the problem. The GameObject::count(counter) isn''t working anymore, as it is only called for every object in the game object list and it increases the count only by one. Thus the whole unit is counted as a single object, which isn''t true.

One solution for the problem is to inherit class Man : protected GameObject and then inherit Commander from Man. Now Commander can override the count() method so that it includes all the men in his unit. count() method still remains unaccessable for outsiders through Man or Commander and thus the users of Man and Commander are insulated from the counting details (and more importantly can''t mess with them).

--

Is the above example a bad design? The answer is probably yes, but I couldn''t come up with any good concrete examples.

Anyway the protected inheritance is a good way to redefine some higher class behavior in a lower class while hiding the implementation details from the user of the middle class.

I believe you should prefer composition to inheritence, but protected inheritence and composition seem to be fairly much on par ... I haven''t actually found a case where I use protected inheritence yet. Are there any advantages to it? (I guess it allows you to pass an object without making the composite class a friend ...)

Anyway, I find it easiest to think about it this way - public, protected and private act the same way for inheritence as they do for variable and function declarations. All inherited functions and variables take whichever is more restrictive of the two access controls. So public functions would become protected, and thus inaccessible to any clients of your class.

--

Games, Anime and more at GKWorld

Meet Bunny luv'' and the girls, ready to perform on your desktop just for you (warning: adult content).

quote:

---

I believe you should prefer composition to inheritence, but protected inheritence and composition seem to be fairly much on par ...

---

Not that it''s relevent to this, but when you need multiple objects from same class, then it''s clearly composition that we need, isn''t it. For instance, if you had a timer class and want a multiple timers in an animation class, you definitely won''t derive the animation class from one timer class. You''d probably put an array of the timer (as many as you need) or give different names to the timer object and put them in as members rather than parent class.

I hate some of the rare ambiguities regarding inheritance and composition. Generally I stick to has/is relationship. The only time I "cheat" a bit on this is when there are so many member functions of other classes that I have to make available though my class, then I''d have to write a method for each one of them in my class if I use composition... (unless I make the object public) that gets annoying and time consuming if there are so many member functions, so in which case I derive my class from it as ''public'' so the previously written member functions is accessible without me having to write a wrapper for every one of them. It is a shortcut sometimes, but certainly a not very good practice, strictly speaking.