1. 类与对象先把这个最基础的概念吃透1.1 从 struct 到 class类到底解决了什么问题很多人学 C 的时候最先接触的其实是struct然后某一天忽然被告知 C 里还有个class两者几乎一样但又不太一样。这个“不太一样”恰恰是理解类的关键。C 语言时代我们用struct把一堆相关数据捆在一起比如一个游戏角色有血量、攻击力、坐标那就定义成一个结构体。但问题是操作这个结构体的函数是散落在外面的你得写attack(player, monster)、move(player, x, y)这种全局函数数据和操作永远是分离的。一旦数据多了函数多了代码就开始乱套——你根本不知道哪些函数真正操作了这个结构体哪些只是碰巧用了它的字段。类把这个局面彻底扭转了。它把数据和操作数据的函数封装在一起数据叫成员变量函数叫成员函数。从此以后不再是“外面有一堆函数操作一堆数据”而是“对象自己知道自己该怎么动”。用一句行话来说这叫从“以数据为中心”转向“以对象为中心”。那class和struct到底有什么区别最直白的说法是struct的默认访问权限是 publicclass的默认访问权限是 private。但这个差别太小了很多人因此觉得两者随便用。我的建议是按照社区惯例来纯粹的数据打包就用struct有行为、有封装、需要维护不变量的就用class。这不是语法要求而是代码可读性的约定。1.2 对象的内存布局栈、堆、静态区类是一个编译期的概念它本身不占内存对象才是运行时的实体它占内存。很多新手搞不清“类和对象的关系”我打个比方类是图纸对象是按照图纸造出来的房子。图纸可以反复用但真正住人的是房子。那对象到底住在哪这取决于你怎么创建它。class Player { public: int hp; int attack; }; int main() { Player p1; // 栈上对象 Player* p2 new Player(); // 堆上对象 static Player p3; // 静态存储区对象 }栈上的对象p1生命周期由作用域决定出了main函数自动销毁不需要你手动管。堆上的对象p2生命周期由你决定new出来之后必须用delete释放不然就内存泄漏。静态对象p3在程序启动时初始化到程序结束才销毁。这三者的区别绝不是“放的位置不一样”这么简单它直接决定了你该怎么管理对象的生命周期。实际项目里我强烈建议优先用栈对象配合作用域天然的资源释放机制这比到处new和delete靠谱得多。真需要动态创建也该用std::unique_ptr和std::shared_ptr这类智能指针接管生命周期而不是裸指针到处飞。1.3 为什么类必须有构造函数我记得自己刚学 C 时有个疑惑为什么不写构造函数也能创建对象后来才明白编译器会偷偷给你生成一个默认构造函数如果你一个构造函数都没写的话。但这个自动生成的构造函数啥也不干成员变量全是不确定值。这就是新手第一个大坑的来源class Player { public: int hp; int attack; }; int main() { Player p; std::cout p.hp std::endl; // 未知值可能是 0可能是垃圾值 }在 Debug 模式下编译器可能帮你把内存清零了看起来是 0到了 Release 模式就是一团随机垃圾。这种“时好时坏”的问题最坑人因为它不会稳定复现。所以我的习惯是只要类里有成员变量就一定要写构造函数把每个成员都初始化到位绝不让对象处于“半生不熟”的状态。这不仅仅是写代码的习惯问题更是一种严谨性的体现。2. 对象的生命周期构造、拷贝、析构2.1 构造函数大家族默认、带参、拷贝、移动构造函数是对象从无到有的入口但“构造”这个动作远比表面复杂。C 里构造函数有好多种每种都有自己出现的时机。默认构造函数不需要参数带参构造函数让你在创建对象时就把初始值传进去拷贝构造函数用一个已有对象来初始化新对象移动构造函数则是 C11 引入的专门解决“把临时对象的东西搬过来”这种场景。这里最容易出问题的其实是初始化列表和赋值之间的区别。class Player { public: Player() : hp_(100), attack_(10) {} // 初始化列表 Player(int hp, int atk) : hp_(hp), attack_(atk) {} private: int hp_; int attack_; };初始化列表和构造函数体内的赋值在效果上看起来差不多但原理不一样。初始化列表是直接初始化成员变量构造函数体内赋值是先默认构造再赋值。对于int这种内置类型差别不大但对于没有默认构造函数的类类型成员或者const成员、引用成员你不用初始化列表就根本编译不过去。此外还有效率上的差别能直接用初始化列表就绝不在构造函数体内赋值。构造函数还有一个很隐蔽的坑——它也是函数会重载但你不能通过返回值区分重载。而且构造函数没有返回值类型这是语法规定的别想着“返回一个错误码”之类的操作那是普通成员函数该干的事。2.2 深拷贝与浅拷贝一个值和一个引用差距比你想象的大拷贝构造函数和拷贝赋值运算符这两个函数如果你不写编译器会自动生成一个“逐成员拷贝”的版本。这个问题对简单类型毫无压力但一旦类里面有指针成员灾难就来了。假设你的类里有个char* name_指向一块动态分配的内存。浅拷贝会把指针的值直接复制过去结果是两个对象的name_指向同一块内存。两个对象析构时同一块内存被delete两次程序直接崩溃或者一个对象修改了内容另一个对象跟着变逻辑完全不在预期内。深拷贝则是重新分配一块内存把原对象指针指向的内容复制一份让两个对象各自拥有独立的数据。解决这个问题有三种路径第一如果你自己写了析构函数、拷贝构造函数或拷贝赋值运算符中的任何一个就应该把另外两个也补齐这被称为“三之法则”如果类还涉及移动语义就升级成“五之法则”。第二更省事的方法——让类里的资源全部用 RAII 类型管理比如std::string、std::vector、智能指针。这样编译器自动生成的拷贝方法就是正确的深拷贝你连写都不用写。第三如果你的类从设计上就不该被拷贝直接把拷贝构造和拷贝赋值删除掉 delete。这三种方式我自己最常用的是第二种。现代 C 的核心思路就是资源管理交给专用类型去做普通类专注自己的业务逻辑。能不让裸指针出现在类里就不让它出现。2.3 析构函数对象“善后”的最后一环析构函数是对象销毁时自动调用的名字是类名前加个波浪号没有参数、没有返回值、不能重载。它的作用是释放对象持有的资源——删除动态内存、关闭文件、释放锁、断开数据库连接。很多人写析构函数只记得delete指针忘了更关键的一点析构时机。栈对象的析构发生在作用域结束处堆对象的析构发生在你delete的那一刻静态对象的析构发生在main结束之后。这个时机的差异是很多隐蔽 bug 的来源。比如你有一个全局对象它的析构函数里调用了另一个已经先被析构的全局对象的方法那轻则拿到垃圾数据重则直接崩溃。所以我的铁律是析构函数里只做释放资源这一件事绝不调用其他对象的复杂方法也绝不抛出异常。析构函数抛异常如果发生在栈展开期间会直接触发std::terminate进程就没了。这是 C 里最严重的错误之一没有之一。2.4 RAIIC 里最值得养成肌肉记忆的思维RAII 全称是 Resource Acquisition Is Initialization中文一般翻译成“资源获取即初始化”。名字听起来高深其实核心思想就一句话资源的生命周期绑定到对象的生命周期对象构造时获取资源对象析构时释放资源。举个最常用的例子。你要往文件里写日志class FileLogger { public: FileLogger(const std::string path) { file_.open(path); if (!file_.is_open()) { throw std::runtime_error(cannot open file); } } ~FileLogger() { if (file_.is_open()) { file_.close(); } } private: std::ofstream file_; };以后你在函数里创建FileLogger logger(log.txt)不管函数是正常返回还是中途抛异常只要出了作用域logger的析构函数必然执行文件必然被关闭。这就叫异常安全。如果不用 RAII你得在每个 return 之前手动 close一旦中间有个分支漏写了资源就泄漏了而且这种泄漏还特别难查。标准库里的std::string、std::vector、std::unique_ptr、std::lock_guard全都是 RAII 思想的体现。可以说理解了 RAII才算真正入了 C 的门。3. 封装与访问控制类的“边界感”从哪来3.1 public、protected、private 的定位与原则访问控制是封装的技术支撑。public是公开接口外部随便调用protected是给派生类用的外部不能碰private是完全私有只有类自己和友元能访问。但是知道三个关键字的意思和会正确划分边界是两码事。我见过太多代码把成员变量全部设为public外部代码直接改内部状态改出了一堆不可预期的结果。比如一个账户类的余额被外部直接减成负数没有任何校验。这本质上就是放弃了封装的防护。我的经验是三个原则第一成员变量默认全部私有这是底线。第二只暴露那些“必须要暴露”的接口多一个都嫌多。第三通过公有成员函数修改变量时要有校验逻辑也就是说成员函数不光是“改值”更是“维持类不变量”的守门员。这样写出来的类才是真正安全的外部使用者不容易误用。protected这个东西要慎重。它的本意是给派生类开个后门但这个后门很容易被滥用。派生类不一定比外部代码更懂你的内部状态过度暴露protected成员实际上是把内部的实现细节外泄给了整个继承体系。现代 C 社区越来越倾向于用private 接口函数来替代protected成员派生类需要访问什么就通过接口获取不直接动底层数据。3.2 友元一把双刃剑能不用就不用友元friend是 C 里一个特立独行的机制它能突破封装让一个外部函数或另一个类直接访问本类的私有成员。它的存在有合理性典型场景是运算符重载。比如你重载operator让一个类能直接输出到std::cout这个函数如果作为成员函数就必须写在类的左侧但输出流的左侧是std::cout不可能是你的类所以你只能把operator写成全局函数而它又想访问类的私有成员这时友元就派上用场了。但友元的滥用很可怕。它的本质是破坏封装边界一旦友元函数多起来私有成员在某种意义上就不私了类的不变量任何人都能绕过接口去破坏。我的态度是能用公有接口解决的事绝不声明友元真要声明友元一定是像operator、operator这种“本身就需要你的私有数据”的场景。而且友元声明不要藏得太隐蔽就写在类定义的显眼位置让后来的维护者一眼看到“这个类对谁开了特权”。3.3 抽象类与普通类接口和实现的分水岭抽象类是含有纯虚函数的类它不能实例化只能被继承。普通类可以实例化是一个可以直接使用的实体。两者最核心的区别就在于“能不能创建对象”和“存在的目的”。抽象类的存在目的是定义接口契约。比如你做一个游戏引擎要支持多种渲染后端于是定义一个抽象类Renderer里面声明纯虚函数draw()、beginFrame()、endFrame()然后写OpenGLRenderer、VulkanRenderer去继承它并实现这些函数。调用方只需要持有Renderer*指针完全不需要关心底层是什么引擎。纯虚函数写成 0意为“本类不提供实现派生类必须实现”。抽象类里也可以有普通成员函数和成员变量但纯虚函数是它的灵魂。这里有一个经常被问到的点抽象类的析构函数必须写成虚析构函数而且最好提供实现。因为当你用Renderer*指向一个OpenGLRenderer对象然后delete这个指针时如果析构函数不是虚的就只会调用Renderer的析构OpenGLRenderer的资源不会被释放内存泄漏就这么产生了。虚析构函数确保通过基类指针删除派生类对象时析构链完整走一遍。这是纯虚函数之外抽象类另一个必须遵守的规则。3.4 const 成员函数不修改对象状态的承诺const在类里有两层意思const对象只能调用const成员函数const成员函数承诺不修改对象的成员变量。第三层则是语法层面的const成员函数内部*this的类型是const的所以你想调用非const的成员函数是编译不过去的。class Player { public: int getHp() const { return hp_; } void setHp(int hp) { hp_ hp; } private: int hp_; }; int main() { const Player p; int hp p.getHp(); // OKconst 成员函数可以被 const 对象调用 p.setHp(10); // 编译错误const 对象不能调用非 const 成员函数 }新手经常忘记在只读函数后面加const结果就是用不了const对象和const引用。我有个习惯凡是语义上不修改对象的成员函数一律写成const没有例外。这既是给编译器看的信息也是给读代码的人看的信息——看到函数签名末尾的const你就知道这个函数没有副作用可以放心调用。但const成员函数偶尔也有想改内部变量的需求比如做缓存或统计。这时候可以把某个成员变量声明为mutable它表示“即使是在 const 成员函数里也可以修改这个变量”。mutable不能滥用它只应出现在“逻辑上不影响对象外部状态”的场合比如缓存、日志计数、互斥锁等。4. static、final、override控制类和对象的“边界行为”4.1 static 成员属于类而不是属于对象static成员变量是所有对象共享的一份数据。你可以理解为它不是每个对象各自带一份而是整个类只存在一份副本。它不属于任何具体对象而是属于类本身。静态成员变量必须在类外单独定义并初始化这个细节让不少人栽过跟头。C17 之后inline static可以简化这个过程允许在类内直接初始化。class Player { public: static int totalPlayers; }; int Player::totalPlayers 0; // 类外定义C17 的替代写法是class Player { public: inline static int totalPlayers 0; // 直接类内初始化 };静态成员函数同样属于类它不依赖具体对象因此内部不能访问非静态成员变量也没有this指针。它适合放那些“和类相关但不需要对象状态”的工具函数。static 在实际工程中的一个经典应用场景就是单例模式。最简单的单例类长这样class Logger { public: static Logger getInstance() { static Logger instance; return instance; } void log(const std::string msg) { // 写日志逻辑 } private: Logger() default; Logger(const Logger) delete; Logger operator(const Logger) delete; };这里用了函数内局部静态变量的初始化机制C11 起局部静态变量在首次控制流经过其声明时初始化并且是线程安全的多个线程同时调用getInstance()也只会有一个实例被创建。构造函数被设为私有外部不能直接创建第二个对象拷贝构造被删除实例永远不会被复制。这个写法是“周知的最好的单例实现”——没用到锁、初始化时机由标准库保证、代码量也少。唯一要注意的是程序退出时单例的析构顺序可能和你预期的有差异别在静态对象析构里去依赖其他静态对象。4.2 final 与 override继承体系中的“刹车”和“标牌”override是在派生类中显式标记“我重写了基类的虚函数”。它本身不影响程序行为但编译器会帮你检查如果基类根本没有这个虚函数或者函数签名对不上编译直接报错。没有override时这种错误常常表现为你自以为重写了虚函数实际上写了个全新的函数而基类的虚函数依然走的是旧逻辑。等运行时才发现行为不对排查成本高得吓人。所以我的规矩是凡是要重写虚函数必须加override一个都不能漏。final的作用是“禁止继承”或“禁止重写”。一个类被声明为final就再也不能被继承一个虚函数被声明为final派生类就不能再重写它。这用在设计上就相当于给继承体系踩了刹车——你已经确定这个类的设计已经完整或者某个虚函数的实现在当前层级是最终版本不允许再变化。final还有一个实际的好处当编译器知道某个虚函数在某个层级不会再被重写时可以做去虚拟化优化把虚函数调用优化成直接调用。这个优化在性能敏感的场景里效果很明显。但不要为了优化而盲目加final它首先是设计意图的表达性能只是附加收益。4.3 虚函数与多态继承体系里的动态调度机制虚函数是 C 实现多态的核心。基类把一个函数声明为virtual派生类可以重写它。当通过基类的指针或引用调用这个函数时程序会根据实际对象的类型在运行期决定该调用哪个版本的函数。class Renderer { public: virtual void draw() 0; virtual ~Renderer() default; }; class OpenGLRenderer : public Renderer { public: void draw() override { // OpenGL 绘制逻辑 } }; void render(Renderer r) { r.draw(); // 运行期决定调用哪个 draw }实现原理上每个包含虚函数的类都有一张虚函数表里面存放着虚函数的地址。每个对象里有一个隐式的虚表指针指向这张表。调用虚函数时程序先通过对象的虚表指针找到虚表再从表中取出函数地址来调用。这就是“动态绑定”。理解了这张虚表你就能明白几个重要推论第一虚函数的调用比普通函数多一次间接寻址有轻微的性能开销但绝大多数场景下可以忽略。第二构造函数中调用的虚函数不会触发动态绑定因为派生类部分还没构造完成。第三虚函数表的存在让每个带虚函数的对象体积都多了一个指针的大小。多态真正强大的地方在于“面向接口编程”。上层代码只依赖抽象基类的接口不需要知道底层具体实现是 OpenGL 还是 Vulkan。这让系统具备了极强的可扩展性——新增一种渲染后端只需要新增一个派生类上层代码一行不用改。5. 类模板与运算符重载让类更具通用性的两个武器5.1 类模板一套代码多种类型类模板让你可以写一套代码服务于多种类型。比如你要写一个容器类不在乎元素是什么类型那就把类型参数化。template typename T class Stack { public: void push(const T value) { data_.push_back(value); } T pop() { T value data_.back(); data_.pop_back(); return value; } private: std::vectorT data_; }; Stackint intStack; Stackstd::string strStack;类模板的核心规则有几点第一成员函数的定义要么写在类模板内部要么写在外部但必须跟template typename T前缀第二类模板的成员函数只有在被实际调用时才会实例化也就是说一个成员函数里写了错误代码只要你不调用它编译就不会报错第三“类模板名称不能重复”这种报错通常是因为你在同一个作用域里定义了同名的模板或者在实例化时用了不完整的类型。模板实例化发生在编译期所以它不参与运行期的动态绑定虚函数不能是模板函数这里的例外是成员函数模板但它不能是虚函数。模板代码通常要写在头文件里因为编译器在实例化时需要看到完整的定义。这就给项目组织带来了一些麻烦但习惯之后就不是问题。类模板的威力在于泛型编程。标准库里的std::vectorT、std::mapK, V、std::unique_ptrT全都是类模板。你写类模板本质上是在抽象“类型无关的逻辑”这比抽象具体类型要高一个维度但相应的学习曲线也会陡一点。5.2 运算符重载让自定义类型表现得更自然运算符重载是 C 一个极具争议的特性。支持者说它让自定义类型用起来像内置类型反对者说它容易过度使用导致代码难懂。我的立场是折中的该重的重不该重的绝不重。最该重载的就是operator和operator用于流输出和输入。它们必须是全局函数否则流对象没法在左侧调用你的重载。class Point { public: friend std::ostream operator(std::ostream os, const Point p); friend std::istream operator(std::istream is, Point p); private: int x_; int y_; }; std::ostream operator(std::ostream os, const Point p) { os ( p.x_ , p.y_ ); return os; }注意operator返回的是std::ostream这样才能链式调用std::cout p1 p2。参数中左侧是流右侧是要输出的对象。因为是全局函数想访问私有成员就必须声明友元。赋值运算符operator也是高频重载点。它的实现有个著名套路叫“copy-and-swap”核心是先构造一个临时副本再和当前对象交换这样既保证了异常安全也顺带处理了自赋值问题。class String { public: String operator(String other) { swap(other); return *this; } private: char* data_; };这段代码里参数是传值的传入时会走拷贝构造背后利用的是“以值传参即拷贝”这个特性。函数体内直接换资源代码简洁行为也正确。但这里有个前提类的 swap 得是自己实现的最好用std::swap的底层逻辑。还有一个很重要的原则重载运算符不应该改变运算符本身的意义。用来实现减法、用来比较对象是否相等这类做法是最让人深恶痛绝的。运算符的语义要直观不要做反常规的设计。5.3 “表达式必须包含类类型”到底是什么错这个报错对于新手几乎是必踩的坑。它最常见的出现场景是你把一个指针当成了对象来用点操作符。Player* p new Player(); p.hp 100; // 编译报错表达式必须包含类类型p的类型是指针不是对象。指针的类型是Player*不是PlayerPlayer才包含成员。所以你需要用箭头操作符-p-hp 100;这个报错的本质是编译器发现你“点”了一个不含成员的表达式。还有一种常见场景是把函数名当成变量来用或者用了不完整的类型。遇到这种报错第一反应是检查左边到底是对象、指针还是引用。如果是指针就用-或者先解引用再用.如果想写法统一可以写成(*p).hp但这不如-直观。6. 字符串数组初始化与“判断类有某个方法”的黑魔法6.1 字符串数组初始化几种方式的细微区别C 里的字符串有两种形态C 风格字符串数组和std::string。很多人一上来就抱怨 C 字符串难用很多时候是没分清这两者。C 风格字符串数组的初始化写法char str1[] hello; // 自动推导大小含结尾 \0共 6 个字符 char str2[6] hello; // 显式指定大小必须留一个给 \0 char str3[6] {h, e, l, l, o, \0}; // 字符数组逐字符初始化注意字符串数组结尾必须有一个空字符\0。如果str2的大小写成了 5编译器会直接报错因为hello需要 6 个字符的空间。用std::string就省心多了std::string s1 hello; std::string s2(hello); std::string s3 std::string(hello);实际开发中绝对优先用std::string它会自动管理内存、支持动态增长、重载了各种运算符。只有在需要兼容 C 接口比如调用fopen时需要const char*时才转成 C 风格字符串用s.c_str()获取底层指针。6.2 C 判断类是否有特定方法SFINAE 与 C17 的 if constexpr这是一个在泛型编程里非常实用的技巧写一个模板让它能自动识别某个类是否有某个成员函数。比如你想写一个通用函数如果对象有save()方法就调用它没有就走默认逻辑。在 C17 之前这需要借助 SFINAESubstitution Failure Is Not An Error和std::void_t这种类型萃取技巧代码相当绕template typename T, typename void struct has_save : std::false_type {}; template typename T struct has_saveT, std::void_tdecltype(std::declvalT().save()) : std::true_type {};C17 提供了if constexpr极大简化了这个过程template typename T void process(T obj) { if constexpr (requires { obj.save(); }) { obj.save(); } else { // 默认逻辑 } }requires表达式是 C20 才引入的但 C17 里也可以用std::is_void_t配合if constexpr或者直接先用decltype探测template typename T, typename void struct has_save : std::false_type {}; template typename T struct has_saveT, std::void_tdecltype(std::declvalT().save()) : std::true_type {}; template typename T void process(T obj) { if constexpr (has_saveT::value) { obj.save(); } else { // 默认逻辑 } }注意一个关键点if constexpr的 false 分支在实例化时会被丢弃里面的代码不会参与编译。这意味着你可以在这个分支里调用那些对某些类型根本不存在的函数也不会报错。这比传统if要好得多传统的if两个分支都要编译而有些类型根本没有save()方法传统写法直接编译失败。这个技巧在处理异构类型集合、设计接口适配层时特别有用。它让泛型代码有了“类型自省”能力但绝不等于运行期的反射。它是在编译期就确定好走哪个分支没有任何运行期开销。7. 从类与对象出发构建一个可扩展的小项目7.1 小游戏中的类设计一个角色系统的思路学了这么多语法最容易犯的毛病就是“纸上谈兵真到写项目时还是不知道类该怎么划分”。其实只要你写过一个稍完整的小项目比如一个文字冒险小游戏、一个棋类小游戏这些抽象概念立刻就能落地。以文字冒险游戏为例核心类可以这样划分Player负责玩家状态血量、攻击力、背包、位置。Monster负责敌人状态血量、攻击力、掉落物。Scene负责场景描述包含场景内的物品、怪物以及通往其他场景的连接。Game负责整个游戏循环读玩家输入、调度场景切换、触发战斗。GameState负责存盘点、存档和读档。每个类只干一件事类与类之间的依赖也尽量单向流动Game依赖Scene和Player但Scene不依赖Game。这样写的好处是你想给游戏加一个新功能比如加个商店系统只需要新建一个Shop类再让Game在合适的时机调用它不需要把原有的代码推倒重来。玩家类还可以进一步抽象出一个基类Character玩家和怪物都继承它。Character里放血量和攻击力Player增加背包操作Monster增加掉落逻辑。继承在这里不是为了炫技而是因为玩家和怪物确实共享了大量属性和行为提取一个基类能有效避免代码重复。战斗系统的设计也可以用到多态你定义一个接口Skill里面有纯虚函数execute(Character target)然后写FireBallSkill、HealSkill、PoisonSkill去实现它。往后新增技能不需要改战斗系统的核心逻辑只需要新增一个类备好后在技能表里注册。这就是多态和接口设计带给代码最大的好处——可扩展性。7.2 类与随机数如何管理“看起来随机”的对象状态C 里生成随机数需要用random库。标准的姿势是先创建一个随机数引擎std::mt19937_64再定义一个分布std::uniform_int_distributionint或std::uniform_real_distributiondouble然后通过分布对象来生成随机数。在类设计时如果你把随机数引擎直接塞进一个类里当成员变量要小心它的初始化时机。随机数引擎需要种子种子用std::random_device提供更好class Game { public: Game() : rng_(std::random_device{}()), dist_(1, 100) {} int nextRandom() { return dist_(rng_); } private: std::mt19937_64 rng_; std::uniform_int_distributionint dist_; };这里把引擎和分布都作为类的成员好处是同一个Game对象多次调用nextRandom()时随机数序列是连贯的。如果你每次调用都重新创建一个引擎并用当前时间做种子那在同一秒内多次调用很容易得到相同的结果这在骰子系统、掉落系统中是绝对不能接受的。还有一个容易踩坑的点Game被复制时会连随机数引擎一起复制导致两个副本的随机数序列完全一样。这可能是 bug也可能是刻意为之——比如你想实现“序列回放”功能时复制引擎反而成了特性。但必须清楚这个行为否则调试时你会发现两个对象“步调一致”让人摸不着头脑。7.3 错误处理在类设计中的位置异常与对象状态很多新手在写类时没有考虑过“出错了怎么办”这个问题。比如一个对象的方法执行失败是返回错误码还是抛出异常在现代 C 工程里异常是主流。构造函数没法返回错误码这是关键因素——如果一个对象在构造过程中失败那它就不应该被创建出来异常是在这个场景下唯一合理的报错方式。析构函数则刚好相反绝不能抛出异常否则会引发std::terminate。所以我的经验是构造函数可以用异常报告初始化失败普通成员函数如果失败后果严重且调用方无法忽略就抛异常如果失败是可预期的、调用方可能需要基于结果做流程分支的就返回std::optional或错误码。比如一个findPlayer(int id)函数如果查无此人返回std::optionalPlayer比抛异常更合理因为“查无此人”不是什么异常状况就是一个普通的结果。类设计时把错误处理策略定好整个项目的健壮性会上一个台阶。最怕的做法是对象内部出错后默默吞掉或者把一个对象留在“半成功”的状态里不做任何标记。这种坑排查起来极其痛苦我踩过太多次了。8. 常见问题排查从报错信息到设计失误问题现象常见原因排查思路“表达式必须包含类类型”把指针当对象用点号或把函数当变量用检查点号左边的类型指针用-对象成员是垃圾值构造函数没初始化或初始化不完整用初始化列表把所有成员初始化到位程序崩溃发生在析构时浅拷贝导致同一内存被 release 两次检查拷贝构造和拷贝赋值是否做了深拷贝“类模板名称不能重复”同一作用域里定义了同名模板或重复 include检查头文件守卫、命名空间、类名冲突const 对象调不了函数成员函数没加 const只读函数一律加 const虚函数没生效忘了加 override签名不匹配派生类重写处加 override 让编译器检查其实大部分 C 新手遇到的问题根源都不是语法不会而是对“类型”和“对象”这两个概念的理解不透彻。类型是编译期的概念对象是运行期的实体。编译器报的每一条错都是在告诉你“你写出来的代码在类型层面就站不住脚”。调试 C 程序我最常用的一套组合拳是先看报错信息如果看不懂就去把出错那一行左边所有表达式的类型理一遍用 IDE 的变量提示或者打印decltype的结果理清楚了类型再结合对象的生命周期来看内存问题。80% 的问题在这个流程下都能定位。我自己的项目里长期维持着几条纪律你也可以试试类定义里成员变量全部用初始化列表初始化不让任何成员处于未初始化状态。类含有裸指针时先把拷贝构造、拷贝赋值、析构函数写完再写业务代码。重写虚函数一律加override类不可继承时加final。单例类的拷贝构造和拷贝赋值直接 delete。析构函数不抛异常、不调用虚函数。引入第三方库的类时先确认它是值语义还是引用语义再决定如何存储。这六条纪律是我写 C 多年踩坑踩出来的每一行都是血泪教训。照着做能避开绝大多数低级问题。C 的类与对象体系非常庞大我在这篇文章里覆盖了从基础概念到内存管理、从封装继承到多态、从模板到错误处理的完整链路。有些内容比如移动语义、完美转发、模板元编程没有展开细讲因为它们单拎出来就是一门单独的课题。等你在类与对象这个层面站稳了脚跟再往那些方向深入会顺畅得多。
