Member Avatar for johndoe444

Hi,

class base {
   int i, j;
public:
   void set(int a, int b) { i=a; j=b; }
   void show() { cout << i << " " << j << "\n"; }
};
class derived : public base {
   int k;
public:
   derived(int x) { k=x; }
   void showk() { cout << k << "\n"; }
};

In the declaration above why is it necessary to declare base as public(or private) within the definition of class derived?

  • 3 Contributors
  • 2 Replies
  • 135 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by Bench

Dani AI

Generated

Below is a concise, practical summary that clarifies why you write : public / : private after the base class and what it actually changes, expanding on points from , and .

The inheritance-specifier controls two different things: (1) how the base class's members are exposed through the derived type (the derived type's public/protected interface), and (2) whether code outside the derived class can convert a derived*/derived& to base*/base&. Public inheritance preserves the base's interface and allows implicit upcasts; non-public inheritance hides the base's interface and prevents outside implicit conversions. This is why you must declare the access: the language needs to know whether you intend the derived type to be a public subtype or an implementation detail.

Concrete effects (rules summarized)

  • Public inheritance: base public -> public in derived; base protected -> protected in derived. Implicit conversions Derived* -> Base* are allowed.
  • Protected inheritance: base public/protected -> protected in derived.
  • Private inheritance: base public/protected -> private in derived. Implicit upcasts are not available to general client code (they remain usable inside the derived class and its friends).

Example illustrating convertibility:

struct Base { virtual ~Base() = default; };
struct Pub  : public Base {};
struct Priv : private Base {};

Base* p = new Pub;   // OK
Base* q = new Priv;  // error: conversion not accessible

Practical guidance

  • Use public inheritance when you mean "is-a" and want substitutability and polymorphism (ensure the base has a virtual destructor if deletion via base is possible).
  • Use private inheritance only when you need implementation reuse plus access to protected members, or when you want to reuse non-virtual functions without exposing the base interface — otherwise prefer composition.
  • Initialization order (base subobjects before derived members) is fixed by the language and does not depend on the access specifier.

Further reading: Derived classes and .

Recommended Answers

All 2 Replies

Member Avatar for NicAx64

the default inheritance is private inheritance if you not explicitly mentioned.

well private inheritance is more likely an has-a relationship than the is-a relationship. and the bottom line is use private inheritance where you can't avoid and use composition where every elsewhere.

there are three object oriented concepts relate to this,
source :
quote--
· Decorator Modify behavior, without modifying an existing interface

· Adapter Modify interface without modifying behavior

· Wrapper Provide interface for, and services to, behavior that is defined elsewhere
quote--
and the C++ language bottom line is always use private inheritance
that you can't avoid it. ( source from C++ FAQ ).

Member Avatar for Bench

I believe private inheritance more accurately represents "implemented in terms of"; which is slightly different to 'has a'; the main difference being that a privately inherited implementation is guaranteed to be initialised before a class' own private members. Something which is associated with a few interesting initialisation tricks.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.