C++继承通过派生类从基类获取成员实现代码复用和类型层级构建，形成“is-a”关系。使用class 派生类 : 访问修饰符 基类语法，访问修饰符控制基类成员在派生类中的可见性。内存布局上，派生类对象包含完整的基类子对象，基类成员位于派生类成员之前，确保基类指针可安全指向派生类对象。构造函数调用顺序为先基类后派生类，析构则相反，先派生类后基类，若基类析构函数非虚，通过基类指针删除派生类对象将导致资源泄露，故需将基类析构函数声明为virtual以支持多态删除。公有继承表达“is-a”关系，保持基类接口开放；保护继承将基类public和protected成员变为protected，限制外部访问；私有继承将基类成员变为private，仅派生类自身可访问，适用于“implemented-in-terms-of”场景，隐藏实现细节。
C++继承的核心在于代码复用和构建类型层级。它允许一个类（派生类）从另一个类（基类）中获取属性和行为，形成一种“is-a”的关系，比如“猫是一种动物”。这不仅仅是简单的复制粘贴，更是一种深层次的抽象和扩展机制，让我们的程序设计变得更有条理、更具弹性。
解决方案
C++中实现继承，说白了就是声明一个新类时，指定它要从哪个已有的类那里“继承”点什么。语法上非常直观：
class 派生类名 : [访问修饰符] 基类名 { /* ... */ };。这里的访问修饰符（public,
protected,
private）决定了基类成员在派生类中的可见性。
具体到实现，编译器在背后做了不少工作。当你定义一个派生类对象时，它会先在内存中为基类部分分配空间，然后才是派生类特有的成员。你可以把它想象成一个俄罗斯套娃，基类是外层或内层的一个部分。派生类自然而然地拥有了基类的所有非静态成员变量和成员函数（除了基类的构造函数、析构函数和赋值运算符，它们不会被直接继承，但可以被调用）。
这里面最让我着迷的，是它如何通过虚函数（
virtual）和多态性，让程序在运行时还能根据对象的实际类型来决定调用哪个函数。这是实现所谓“接口”和“行为抽象”的关键。如果没有虚函数，派生类重写基类方法就只是“隐藏”而非“覆盖”，失去了那种动态绑定的魔力。当然，这又牵扯到虚函数表（vtable）这些底层机制，但从使用者的角度看，它让我们可以用基类指针或引用去操作派生类对象，并且行为符合预期，这才是真正强大的地方。
立即学习“C++免费学习笔记（深入）”；
#include#include class Animal { public: std::string name; Animal(const std::string& n) : name(n) { std::cout << "Animal constructor: " << name << std::endl; } virtual void speak() const { // 虚函数，允许派生类覆盖 std::cout << name << " makes a sound." << std::endl; } ~Animal() { std::cout << "Animal destructor: " << name << std::endl; } }; class Dog : public Animal { // 公有继承 public: std::string breed; Dog(const std::string& n, const std::string& b) : Animal(n), breed(b) { // 调用基类构造函数 std::cout << "Dog constructor: " << name << ", " << breed << std::endl; } void speak() const override { // 覆盖基类虚函数 std::cout << name << " barks loudly!" << std::endl; } void fetch() const { std::cout << name << " fetches the ball." << std::endl; } ~Dog() { std::cout << "Dog destructor: " << name << ", " << breed << std::endl; } }; // int main() { // Animal* myAnimal = new Dog("Buddy", "Golden Retriever"); // myAnimal->speak(); // 调用 Dog::speak() // // myAnimal->fetch(); // 编译错误，Animal指针不知道fetch方法 // delete myAnimal; // return 0; // }
基类与派生类的内存布局是怎样的？
当你创建一个派生类对象时，它在内存中的组织方式其实挺有意思的。简单来说，一个派生类对象会包含一个完整的基类子对象（subobject），然后才是派生类自己声明的成员。你可以把它想象成一个结构体，里面第一个成员是基类类型，后面跟着派生类自己的成员。
举个例子，如果
Animal类有
name成员，
Dog类在继承
Animal后又增加了
breed成员。那么一个
Dog对象的内存布局大致会是：先是
Animal类的
name成员（以及可能的虚函数表指针
vptr，如果类有虚函数），紧接着才是
Dog类的
breed成员。这种布局方式确保了派生类对象在任何时候都能像一个完整的基类对象那样被处理，因为它确实包含了基类的所有“零件”。
这种布局的直接好处是，你可以安全地将派生类对象的地址隐式转换为基类指针，因为基类部分总是在派生类对象的起始位置（或紧随vptr之后）。反过来就不行了，因为基类指针并不知道派生类后面还有什么额外的数据。了解这一点，对于理解C++对象模型和调试一些内存相关的错误非常有帮助。
继承中构造函数和析构函数的调用顺序有什么讲究？
这绝对是C++继承里一个常考点，也是理解对象生命周期管理的关键。我个人觉得，理解这个顺序，就像理解盖房子和拆房子的步骤。
构造函数调用顺序： 总是先调用基类的构造函数，然后才是派生类的构造函数。 这很好理解，就像你盖房子，得先有地基（基类部分）才能往上盖楼层（派生类部分）。派生类的成员可能需要用到基类已经初始化好的资源或状态，所以基类必须先准备就绪。在派生类的构造函数初始化列表中，你可以显式地调用基类的特定构造函数，如果不写，编译器会默认调用基类的无参构造函数。
析构函数调用顺序： 总是先调用派生类的析构函数，然后才是基类的析构函数。 拆房子嘛，得从上往下拆。派生类可能管理着一些资源，这些资源又依赖于基类提供的服务或数据。如果先析构了基类，那么派生类在执行自己的清理工作时，可能会发现它所依赖的基类部分已经不存在了，这就会导致未定义行为。所以，派生类先把自己特有的部分清理干净，再让基类去清理它自己的部分，这才是安全的做法。
一个常见的陷阱是，如果基类有虚函数，但它的析构函数不是虚函数，那么通过基类指针删除派生类对象时，只会调用基类的析构函数，导致派生类部分的资源泄露。所以，我的建议是，只要你的类将来有可能被继承，并且通过基类指针进行多态删除，那么基类的析构函数一定要声明为 virtual
。这能确保在多态删除时，派生类和基类的析构函数都能被正确调用。
何时选择公有继承、保护继承或私有继承？
选择哪种继承方式，其实是关于“关系”和“访问权限”的设计哲学。这三种方式定义了基类成员在派生类中的可见性，也间接决定了派生类对象对外表现出的行为。
公有继承（public
inheritance）：
这是最常见、最符合直觉的继承方式，它表达的是一种强烈的“is-a”关系。比如“
Dog是一种
Animal”。在这种模式下，基类的
public成员在派生类中依然是
public，
protected成员依然是
protected。外部代码可以通过派生类对象访问基类的
public成员。这是实现多态性（通过基类指针或引用操作派生类对象）的基础。如果你想让派生类完全继承基类的接口和行为，并且允许外部像操作基类一样操作派生类，那就用公有继承。
保护继承（protected
inheritance）：
这种方式比较少用，但有它的特定场景。它把基类的
public和
protected成员都变成了派生类的
protected成员。这意味着，派生类自己可以访问这些成员，派生类的派生类也可以访问，但外部代码无法通过派生类对象直接访问基类的
public成员。它表达的可能是一种“实现细节”上的继承，或者说，基类对派生类来说是其内部实现的一部分，但不对外暴露基类的接口。我个人觉得这种方式有点像一种折衷，既不像公有继承那么开放，又比私有继承提供了更多的内部访问权限。
私有继承（private
inheritance）：
私有继承表达的是一种“implemented-in-terms-of”关系，或者说“has-a”的实现方式。它把基类的
public和
protected成员都变成了派生类的
private成员。这意味着，只有派生类自己可以访问基类的成员，外部代码和派生类的派生类都无法访问。从外部看，派生类对象与基类对象没有任何关系。这种方式常被视为组合（composition）的一种替代方案，尤其是在你需要访问基类的
protected成员，或者需要重写基类的虚函数时。它允许你重用基类的实现，但又完全隐藏了基类的接口，不向外暴露。比如，你可能想让一个
Logger类“继承”一个
FileStream来利用其文件操作能力，但你不想让
Logger对象被当作
FileStream来使用，这时私有继承就很有用。
选择哪种方式，最终取决于你想要表达的对象关系和访问控制策略。公有继承是默认选择，除非你有明确的理由去限制接口或表达更复杂的内部实现关系。
