private or public inheritance?

[KIBO]

After reading an article on private inheritance Im wondering if I should use private inheritance in the following example instead of public.

class CAnimation
{
  explicit CAnimation(unsigned long Timer);

  virtual ~CAnimation();

protected:
  virtual Status Init() = 0;
  virtual void Render() = 0;

  virtual Status Update(unsigned long TimeElapsed) = 0;
  virtual void Cleanup() = 0;

  virtual bool IsDone();
};

class CardDealAnimation : public CAnimation
{
public:
  CardDealAnimation(CSprite *HandSprites, int HandSize);

  virtual Status Init();

  virtual void Render() {}
  virtual Status Update(unsigned long Time) {}
  virtual void Cleanup() {}
  virtual bool IsDone() {}
};

I used public till now, but Im thinking its not the right choice. The CardDealAnimation does model the "is-a" relationship but it should not provide an interface to further subclasses. So whats better, public or private or is it both 100% correct from a modeling POV?

Here's the article

Cprogramming.com - Tutorials - Understanding Private Inheritance

[bithub]

I used public till now, but Im thinking its not the right choice. The CardDealAnimation does model the "is-a" relationship but it should not provide an interface to further subclasses. So whats better, public or private or is it both 100% correct from a modeling POV?

Here's the article

Cprogramming.com - Tutorials - Understanding Private Inheritance

In the case of CardDealAnimation and CAnimation it looks like you should use public or protected inheritance. It doesn't matter which of those you use since you override all of CAnimation's methods.

Private inheritance should be used when the relationship is "has-a", not "is-a".

[grumpy]

I used public till now, but Im thinking its not the right choice. The CardDealAnimation does model the "is-a" relationship but it should not provide an interface to further subclasses. So whats better, public or private or is it both 100% correct from a modeling POV?

There's very rarely any such thing as "100% correct from a modelling POV". Every alternative way of modelling a relationship has both a set of benefits and a set of associated trade-offs. The selection of a particular approach is therefore based on some preference for a set of benefits while accepting a few niggles that make that choice non-ideal.

If CardDealAnimation does model an "is-a" relationship then, in practice, public inheritence is the way to go.

Why do you consider that CardDealAnimation "should not provide an interface to further subclasses"? Every class provides some form of interface to any classes derived from it. If you mean that no classes should be allowed to be derived from CardDealAnimation, then there are options;

1) Make CardDealAnimation's constructors (except its copy constructor) private, and provide public static members that create and return an object by value. Only those static members can create an object, so there is no way to create an instance of a derived class - as they cannot invoke private constructors of a base class.

2) Have CardDealAnimation exploit private virtual inheritence from a helper class that has all its constructors private, and which declares CardDealAnimation as a friend.

There are also non-technical options (eg documentation stating that the class is not to be derived from).