1. 內(nèi)容整體設(shè)計與思路拆解1.1 這節(jié)“下”到底該講什么“C之類和對象下”看到這個標(biāo)題如果你剛學(xué)完“上”和“中”心里應(yīng)該有個預(yù)期——上篇講了類的定義、訪問限定符、封裝中篇大概率聊了構(gòu)造函數(shù)、析構(gòu)函數(shù)、this指針、const成員函數(shù)這些基礎(chǔ)中的基礎(chǔ)。那這個“下”字承接的就是把類從“能跑”推向“能用、能穩(wěn)、能復(fù)用”的關(guān)鍵部分拷貝構(gòu)造與賦值、深淺拷貝的坑、初始化列表的底層邏輯、static成員、友元、內(nèi)部類以及運(yùn)算符重載和繼承多態(tài)的銜接。說白了這本書/這套課程的作者把類和對象拆成上中下三篇下篇就是“面向?qū)ο筮M(jìn)階的入口”。它不是讓你再背一遍概念而是要你開始思考一個類設(shè)計出來以后怎么讓別人用得舒服怎么在內(nèi)存層面不出亂子怎么把代碼寫得像標(biāo)準(zhǔn)庫里的string、vector那樣自然。我在帶新人的時候常說判斷一個人C到底入沒入門不是看他會不會寫class而是看他能不能講清楚“什么時候必須自定義拷貝構(gòu)造函數(shù)”“為什么傳參盡量傳引用”“析構(gòu)函數(shù)為什么最好加virtual”。這些內(nèi)容恰恰就是“下”篇的重點(diǎn)。1.2 為什么說這塊內(nèi)容是C的分水嶺你可能在學(xué)“上”和“中”的時候感覺C也就是個加了類的C語法上多幾個關(guān)鍵字而已。但到了“下”篇你會第一次真正直面C最硬核的東西——內(nèi)存管理、對象生命周期、類型系統(tǒng)對語法的滲透。舉個例子很多人寫了一個String類里面有一個char*指針成員。如果直接使用編譯器默認(rèn)生成的拷貝構(gòu)造函數(shù)兩個對象的指針會指向同一塊堆內(nèi)存析構(gòu)的時候double free直接崩掉。這個問題不深究拷貝控制的底層邏輯是根本解決不了的。而把這層紙捅破之后你再看stoi、to_string這類標(biāo)準(zhǔn)庫工具的源碼才看得出門道。所以這篇文章不打算幫你“快速過完知識點(diǎn)”而是把“下”里最核心的幾個硬骨頭逐個嚼碎配上可運(yùn)行的代碼和我在實戰(zhàn)里踩過的坑。不管是自學(xué)的朋友、在培訓(xùn)班掙扎的同學(xué)還是準(zhǔn)備校招找C開發(fā)崗的應(yīng)屆生都能從中拿到可以直接用的東西。2. 構(gòu)造函數(shù)進(jìn)階初始化列表與隱式轉(zhuǎn)換的底層邏輯2.1 初始化列表到底在初始化什么先說結(jié)論初始化列表里的內(nèi)容是真正的“初始化”構(gòu)造函數(shù)體內(nèi)的賦值操作在對象已經(jīng)完成構(gòu)造之后才發(fā)生。兩者有本質(zhì)差距尤其是成員變量是const、引用或者沒有默認(rèn)構(gòu)造函數(shù)的自定義類型時你只能靠初始化列表不能在函數(shù)體內(nèi)“賦值”。來看這個例子class Config { public: Config(int id, const std::string path) : id_(id), // 直接初始化一次到位 path_(path), // 調(diào)用std::string的拷貝構(gòu)造 ref_(id_), // 引用成員必須用初始化列表 const_val_(100) // const成員必須用初始化列表 { // 如果在函數(shù)體里寫 id_ id那不是初始化是賦值 } private: int id_; std::string path_; int ref_; const int const_val_; };這里有個細(xì)節(jié)容易翻車成員變量的初始化順序完全按它們在類中聲明的順序來跟初始化列表里寫的順序無關(guān)。所以如果你把ref_(id_)寫在const_val_前面沒問題但如果某個成員依賴另一個先初始化就一定調(diào)整聲明順序否則會出現(xiàn)“使用了未初始化對象”這種幽靈bug。實戰(zhàn)里最典型的例子一個成員A的構(gòu)造函數(shù)需要另一個成員B作為參數(shù)B一定要先聲明。很多人只改初始化列表順序不改聲明順序排查半天發(fā)現(xiàn)根本沒生效就是這個原因。另外在“下”篇里通常還會提到委托構(gòu)造函數(shù)也就是一個構(gòu)造函數(shù)調(diào)用另一個構(gòu)造函數(shù)。這個機(jī)制在類成員很多、構(gòu)造邏輯分層時非常實用比如默認(rèn)構(gòu)造函數(shù)委托給帶參構(gòu)造函數(shù)默認(rèn)參數(shù)由常量補(bǔ)上。class HttpRequest { public: HttpRequest() : HttpRequest(, 80) {} HttpRequest(const std::string host, int port) : host_(host), port_(port) { // 真正的初始化邏輯 } };2.2 explicit關(guān)鍵字隱式轉(zhuǎn)換的剎車片單參數(shù)的構(gòu)造函數(shù)在沒有explicit修飾的情況下會允許編譯器做隱式類型轉(zhuǎn)換。這在某些場景下很方便但也很容易引入隱蔽的錯誤。class AuthToken { public: AuthToken(const std::string token) : token_(token) {} // 沒有explicit時下面這句是合法的 // void login(AuthToken token); // login(abc123); // 編譯器自動構(gòu)造了一個臨時對象 private: std::string token_; };你可能會說自動構(gòu)造臨時對象省了調(diào)用的麻煩這不是壞事嗎但問題是如果這個構(gòu)造函數(shù)還有別的副作用比如發(fā)送一次網(wǎng)絡(luò)請求、寫一條日志、申請一塊大內(nèi)存那隱式轉(zhuǎn)換就會在你不防備的地方觸發(fā)。我調(diào)試過一個項目某個模塊性能莫名其妙變差最后定位到是一個單參數(shù)構(gòu)造函數(shù)在循環(huán)里被隱式調(diào)用了上萬次。建議除非你有十足的理由比如模擬數(shù)值類型的隱式提升否則所有單參數(shù)構(gòu)造函數(shù)都加explicit。標(biāo)準(zhǔn)庫里的std::string、std::vector等容器它們的單參數(shù)構(gòu)造函數(shù)也都帶explicit這就是業(yè)界共識?；叵胍幌聼嵩~列表里“java lambda調(diào)用內(nèi)部類示例”這種跨語言問題實際上C里的lambda與函數(shù)對象也依賴類的運(yùn)算符重載這個放到第5章細(xì)說。3. 拷貝控制深淺拷貝與三/五法則3.1 編譯器默認(rèn)生成的拷貝語義很多初學(xué)者想當(dāng)然地認(rèn)為類里面有指針成員默認(rèn)拷貝構(gòu)造也能逐一拷貝成員指針拷貝了就拷貝了唄數(shù)據(jù)不都共享了對共享了但共享的是同一塊堆內(nèi)存的地址。兩個對象各自析構(gòu)的時候都對這塊內(nèi)存調(diào)用delete——double free幾乎是必然的。我們先看默認(rèn)行為的代碼表現(xiàn)class UserBuffer { public: UserBuffer(size_t size) { data_ new char[size]; size_ size; } ~UserBuffer() { delete[] data_; // 兩個對象double free的元兇 } private: char* data_; size_t size_; }; UserBuffer a(1024); UserBuffer b(a); // 默認(rèn)逐成員拷貝b.data_ a.data_ // 函數(shù)結(jié)束時a、b各自析構(gòu)同一塊堆內(nèi)存被釋放兩次這種錯誤在release版本里可能不會立刻崩但會在下一次new或者delete的時候隨機(jī)爆炸。熱詞里有“c#調(diào)用c出現(xiàn)access violation c0000005”這類問題相當(dāng)一部分就源于C側(cè)的對象在跨模塊傳遞時發(fā)生了淺拷貝堆內(nèi)存被重復(fù)釋放或者提前釋放。看起來是C#和C的互操作問題根子上還是C對象的拷貝控制沒寫對。3.2 深拷貝與正確寫法深度拷貝就是讓新對象擁有獨(dú)立的資源拷貝的不是指針本身而是指針指向的內(nèi)容。class UserBuffer { public: UserBuffer(size_t size) : data_(new char[size]), size_(size) {} // 拷貝構(gòu)造深拷貝 UserBuffer(const UserBuffer other) : data_(new char[other.size_]), size_(other.size_) { std::copy(other.data_, other.data_ size_, data_); } // 拷貝賦值先釋放舊資源再深拷貝同時要處理自我賦值 UserBuffer operator(const UserBuffer other) { if (this ! other) { // 自我賦值檢查 char* new_data new char[other.size_]; // 先申請新空間防止破壞原對象 std::copy(other.data_, other.data_ other.size_, new_data); delete[] data_; // 釋放舊空間 data_ new_data; size_ other.size_; } return *this; } ~UserBuffer() { delete[] data_; } private: char* data_; size_t size_; };這段代碼里有三個容易忽略的細(xì)節(jié)。第一拷貝賦值必須先new再delete順序不能反過來。如果先delete舊空間然后new的時候拋出異常對象就處于“沒有資源”的半死狀態(tài)。第二自我賦值檢查用this ! other雖然現(xiàn)在copy-and-swap更優(yōu)雅但教學(xué)階段先理解這個基本版本更扎實。第三如果你真的不希望對象被拷貝可以直接把拷貝構(gòu)造和拷貝賦值delete掉C11以后這不是難事UserBuffer(const UserBuffer) delete; UserBuffer operator(const UserBuffer) delete;3.3 三/五法則與何時偷懶所謂三法則Rule of Three是說如果一個類定義了析構(gòu)函數(shù)、拷貝構(gòu)造函數(shù)、拷貝賦值運(yùn)算符中的任何一個那這三個最好都自定義或默認(rèn)化default。五法則是在C11又加了移動構(gòu)造和移動賦值進(jìn)來。這不是強(qiáng)迫癥。析構(gòu)函數(shù)的存在本身就是信號——這個類管理了資源。管理資源的類默認(rèn)的逐成員拷貝幾乎必然導(dǎo)致內(nèi)存問題。不過也有偷懶的時刻如果成員全是int、double、std::string、std::vector這樣的RAII類型那根本不需要自定義析構(gòu)和拷貝編譯器默認(rèn)生成的就很完美。只有裸指針、文件句柄、socket、互斥鎖這類“原始資源”才需要勞駕你親自動手。我自己寫代碼時的判斷標(biāo)準(zhǔn)很簡單類里出現(xiàn)裸指針馬上停下來問自己——這個指針需要delete嗎需要的話拷貝控制、析構(gòu)、移動語義一套全做不需要的話用std::unique_ptr或std::shared_ptr封裝掉基本上一勞永逸。4. 靜態(tài)成員、友元與內(nèi)部類4.1 static成員的本質(zhì)與正確使用姿勢static成員屬于類本身不屬于任何一個實例。它存放在靜態(tài)存儲區(qū)整個程序生命周期只有一份。這里有一個經(jīng)常踩坑的知識點(diǎn)static成員變量必須在類外單獨(dú)定義在C17之前因為它不是對象的一部分構(gòu)造函數(shù)初始化不了它。舉個例子class GameSession { public: static int total_sessions_; static const int kMaxPlayers 4; // 整型常量可以在類內(nèi)直接初始化 // ... }; int GameSession::total_sessions_ 0; // 必須在類外定義否則鏈接報錯靜態(tài)成員函數(shù)也很有意思它沒有this指針?biāo)灾荒茉L問static成員不能直接訪問普通成員變量。這種限制看似束縛其實是設(shè)計上的刻意而為——你可以在不創(chuàng)建對象的情況下調(diào)用它例如工廠模式里經(jīng)常用靜態(tài)函數(shù)來創(chuàng)建對象class Logger { public: static Logger Instance() { static Logger logger; // 函數(shù)內(nèi)靜態(tài)局部對象線程安全的懶加載單例 return logger; } void Log(const std::string msg); private: Logger() default; };熱詞里“nav 第1關(guān)對象的創(chuàng)建”應(yīng)該是指某個在線編程平臺關(guān)于對象創(chuàng)建的任務(wù)如果你在那上面卡住了很大概率就是因為沒有理解靜態(tài)成員和實例成員的初始化時機(jī)。創(chuàng)建第一個實例前static成員就應(yīng)該被正確初始化否則后續(xù)實例的行為就是錯的。4.2 友元函數(shù)與友元類的邊界感友元是C里少見的“走后門”機(jī)制一個類可以聲明某個非成員函數(shù)或另一個類是它的友元讓它們訪問私有成員。我理解很多人學(xué)的第一個友元函數(shù)是重載operator因為流運(yùn)算符的左操作數(shù)是ostream不是你自己的類無法把這個函數(shù)寫成類的成員函數(shù)只能借用友元。class Point { friend std::ostream operator(std::ostream os, const Point p); public: Point(double x, double y) : x_(x), y_(y) {} private: double x_, y_; }; std::ostream operator(std::ostream os, const Point p) { os ( p.x_ , p.y_ ); return os; }友元雖然方便但它破壞了封裝。工程上我的建議是友元只用在運(yùn)算符重載和極少數(shù)需要框架代碼訪問內(nèi)部狀態(tài)的場景不要因為“懶”就把另一個類整個設(shè)成友元。熱詞里“staruml類圖怎么畫”“c類圖”說明很多人學(xué)到這里開始畫類圖梳理關(guān)系了那么友元關(guān)系在UML中用帶虛線的連線表示跟關(guān)聯(lián)、聚合這些關(guān)系區(qū)分開一個類如果到處都是友元畫圖時你就能直觀感受到設(shè)計味道不對。4.3 內(nèi)部類嵌套類與外圍類的親密關(guān)系C的嵌套類內(nèi)部類和外層類不是兄弟關(guān)系是嵌套關(guān)系。內(nèi)部類可以訪問外圍類的私有成員但外圍類卻不能訪問內(nèi)部類的私有成員內(nèi)部類不自動擁有外圍類對象的this指針想訪問外圍非靜態(tài)成員必須持有外部對象的引用或指針。這種機(jī)制在實現(xiàn)特定數(shù)據(jù)結(jié)構(gòu)時非常有用。比如STL里list的迭代器很多實現(xiàn)就是list類的嵌套類。嵌套類對外隱藏了實現(xiàn)細(xì)節(jié)使用者只知道list能返回迭代器但迭代器具體長什么樣、成員變量有哪些完全看不到。class BinaryTree { public: class Iterator { public: int Value() const { return node_-value; } private: friend class BinaryTree; // 讓外層能訪問迭代器的私有構(gòu)造 explicit Iterator(Node* node) : node_(node) {} Node* node_; }; Iterator Begin() { return Iterator(root_); } private: struct Node { int value; Node* left; Node* right; }; Node* root_ nullptr; };這個設(shè)計模式值得反復(fù)體會內(nèi)部類的構(gòu)造函數(shù)是私有的外部類通過聲明friend來創(chuàng)建迭代器使用者只能通過Begin()拿到迭代器無法繞過接口直接構(gòu)造一個非法迭代器。這是面向?qū)ο蠓庋b的極好實踐。5. 運(yùn)算符重載讓自定義類型擁有內(nèi)置類型的氣質(zhì)5.1 重載的語法規(guī)則與限制運(yùn)算符重載是C的一個大殺器它能讓你自定義的類用起來和內(nèi)置類型幾乎無差別。但它的規(guī)則和限制相當(dāng)多總結(jié)起來有幾個核心點(diǎn)不能創(chuàng)造新的運(yùn)算符只能重載已有的比如不能發(fā)明**這個運(yùn)算符。不能改變運(yùn)算符的操作數(shù)個數(shù)只能是二元運(yùn)算符-可以是一元負(fù)號也可以是二元減法。很多運(yùn)算符必須作為成員函數(shù)重載比如[]、-、、()因為它們第一個操作數(shù)必須是類類型對象本身。class Matrix { public: Matrix operator(const Matrix rhs) const { Matrix result(*this); // 逐元素相加... return result; } double operator()(int row, int col) { return data_[row * cols_ col]; } };這里有一個必須注意的細(xì)節(jié)重載operator時返回類型通常是值類型而不是引用。因為a b的結(jié)果是一個臨時對象返回引用的話就是懸空引用。重載operator則相反應(yīng)該返回引用*this因為你要修改并返回原對象。5.2 前置與后置的區(qū)分C里前置和后置只能通過參數(shù)來區(qū)分后置版本接受一個額外的int形參僅僅是為了簽名不同。class Counter { public: Counter operator() { // 前置 value_; return *this; } Counter operator(int) { // 后置參數(shù)int只是占位符 Counter temp *this; value_; return temp; } private: int value_ 0; };這個設(shè)計的核心原因后置要先返回舊值所以必須拷貝一份臨時對象無論如何都會有拷貝成本。內(nèi)置類型編譯器能優(yōu)化掉自定義類型就難了。所以循環(huán)里對迭代器走it而不是it不是吹毛求疵而是實打?qū)嵉男阅芤?。熱詞里“c 前綴和”應(yīng)該是指競賽算法里的前綴和數(shù)組那是另一個主題但如果你在做競賽題類和對象的運(yùn)算重載、靜態(tài)成員這些一樣會影響你的代碼組織方式。至少清晰的重載會讓你的高精度大數(shù)或矩陣類用起來像內(nèi)置類型一樣順暢。5.3 賦值運(yùn)算符重載的細(xì)節(jié)補(bǔ)充賦值運(yùn)算符和拷貝構(gòu)造很容易混淆。賦值是在對象已經(jīng)存在的情況下的拷貝b a而拷貝構(gòu)造是通過一個已存在的對象創(chuàng)建一個新對象B a(b);。賦值運(yùn)算符重載時最優(yōu)雅的寫法其實是用copy-and-swapclass StringBuffer { public: StringBuffer operator(const StringBuffer other) { if (this ! other) { StringBuffer temp(other); // 用拷貝構(gòu)造創(chuàng)建臨時對象 Swap(temp); // 把當(dāng)前對象的內(nèi)容與temp交換 } return *this; } private: void Swap(StringBuffer other) noexcept { std::swap(data_, other.data_); std::swap(size_, other.size_); } char* data_; size_t size_; };這種寫法好在哪異常安全。如果第一步拷貝構(gòu)造時內(nèi)存分配失敗當(dāng)前對象保持原樣不會被污染。如果交換操作本身不拋異常那整個過程是“強(qiáng)異常安全保證”的。6. 繼承與多態(tài)下篇與后續(xù)課程的關(guān)鍵銜接6.1 繼承的訪問控制與構(gòu)造順序繼承是面向?qū)ο笤O(shè)計里繞不開的話題類是對象的一張設(shè)計藍(lán)圖繼承就是讓新的藍(lán)圖基于已有藍(lán)圖做擴(kuò)展。C有三種繼承方式public、protected、private。最常見的是public繼承它表達(dá)“is-a”關(guān)系——派生類是一個基類的特殊版本。構(gòu)造順序值得多說一句創(chuàng)建派生類對象時先調(diào)用基類構(gòu)造函數(shù)默認(rèn)調(diào)基類的默認(rèn)構(gòu)造再調(diào)用成員對象的構(gòu)造函數(shù)最后才執(zhí)行派生類自己的構(gòu)造函數(shù)體析構(gòu)順序完全反過來。class Base { public: Base() { std::cout Base constructor\n; } ~Base() { std::cout Base destructor\n; } }; class Derived : public Base { public: Derived() { std::cout Derived constructor\n; } ~Derived() { std::cout Derived destructor\n; } };這段代碼的輸出順序是Base constructor Derived constructor Derived destructor Base destructor這個順序的重要性體現(xiàn)在資源管理上基類負(fù)責(zé)的成員一定先初始化完派生類才能放心使用析構(gòu)時派生類先釋放自己這部分資源基類再釋放公共部分避免出現(xiàn)“基類資源已經(jīng)沒了派生類析構(gòu)函數(shù)還在用”的情況。6.2 virtual虛函數(shù)與動態(tài)多態(tài)虛函數(shù)是C實現(xiàn)動態(tài)多態(tài)的核心手段。用virtual關(guān)鍵字聲明成員函數(shù)通過基類指針或引用調(diào)用時會根據(jù)實際對象類型分發(fā)到對應(yīng)派生類的實現(xiàn)。class Shape { public: virtual double Area() const 0; // 純虛函數(shù)讓Shape成為抽象類 virtual ~Shape() default; // 基類析構(gòu)函數(shù)必須virtual }; class Circle : public Shape { public: explicit Circle(double r) : radius_(r) {} double Area() const override { return 3.1415926535898 * radius_ * radius_; } private: double radius_; };純虛函數(shù)讓基類無法實例化只能做接口和指針類型用。這設(shè)計逼著派生類必須實現(xiàn)Area()否則派生類也無法實例化。這里有個很重要的實戰(zhàn)經(jīng)驗只要一個類有虛函數(shù)它的析構(gòu)函數(shù)幾乎必然是virtual的。否則你通過Shape*指向一個Circle對象delete這個指針時只會調(diào)用Shape的析構(gòu)函數(shù)不會調(diào)用Circle的析構(gòu)——如果Circle里有動態(tài)資源直接泄漏。熱詞里“抽象類和普通類的區(qū)別”問的就是這個問題抽象類不能實例化、通常包含純虛函數(shù)、只能做接口和基類普通類可以實例化可以有完整實現(xiàn)。6.3 final、override和構(gòu)造中不可調(diào)用虛函數(shù)的潛規(guī)則C11以后override關(guān)鍵字能防止你寫錯函數(shù)簽名final能防止某個類被繼承或者某個虛函數(shù)被繼續(xù)重寫這些是現(xiàn)代C代碼里非常推薦的防御性寫法。class HttpServer { public: virtual void HandleRequest() 0; }; class TcpHttpServer final : public HttpServer { public: void HandleRequest() override; // 如果這個類還想被繼承就不能加final };再談一個潛規(guī)則構(gòu)造函數(shù)里不應(yīng)該調(diào)用虛函數(shù)。為什么因為構(gòu)造派生類對象時基類構(gòu)造函數(shù)先執(zhí)行此時對象的動態(tài)類型還是基類類型調(diào)用的虛函數(shù)只會落到基類版本上完全不是你預(yù)期的派生類版本。這個坑我見過新人踩過很多次處理方式通常是不在構(gòu)造函數(shù)里做依賴多態(tài)的事改成用工廠方法或兩段式初始化。7. 常見問題與排查技巧實錄7.1 報錯“表達(dá)式必須包含類類型”到底是什么意思這是從熱詞里捕捉到的一個高頻報錯。其實它的意思非常直白編譯器期望某個表達(dá)式是類對象或類引用但實際拿到的卻是指針、函數(shù)名或者根本沒定義的類型。實際場景最常見的版本是class Point { public: void Print() const { /* ... */ } }; Point* p new Point(1, 2); p.Print(); // 編譯錯誤表達(dá)式必須包含類類型p是Point*不是Point。要訪問指針指向的成員的函數(shù)應(yīng)該用p-Print()。還有一種讓人頭疼的情況你定義了一個成員函數(shù)然后在另一個成員函數(shù)里想調(diào)用它但不小心把函數(shù)名當(dāng)成了類型名class A { public: void foo() {} void bar() { A.foo(); // 錯A是類型名應(yīng)該寫成 foo() 或 this-foo() } };排查這類報錯時先確認(rèn)整個表達(dá)式的最左邊操作數(shù)到底是一個對象、引用還是指針。指針一律-對象一律.類型名稱永遠(yuǎn)不能作為調(diào)用對象。7.2 Access Violation c0000005 的全鏈路排查思路熱詞里有“c#調(diào)用c出現(xiàn)access violation c0000005”這個錯誤字面意思是“內(nèi)存訪問沖突”0xC0000005是Windows上典型的非法內(nèi)存訪問錯誤碼。它和C類相關(guān)的根源幾乎都逃不出以下幾類。第一個是淺拷貝導(dǎo)致的重復(fù)釋放。對象里管理了裸指針拷貝后兩個對象共享同一塊內(nèi)存析構(gòu)時重復(fù)delete。這個問題在同一個進(jìn)程內(nèi)可能被隨機(jī)出現(xiàn)的堆損壞掩蓋在跨語言調(diào)用時往往直接表現(xiàn)為access violation。第二個是導(dǎo)出的DLL接口邊界不一致。C#通過P/Invoke調(diào)用C導(dǎo)出的函數(shù)如果C側(cè)返回一個對象的指針或引用給C#而C#側(cè)按值處理或者釋放了不該釋放的內(nèi)存那必然崩。第三個是類對象的生命周期問題——C側(cè)創(chuàng)建對象返回指針C#側(cè)持有這個指針C側(cè)某個模塊提前delete了對象C#側(cè)下一次訪問時就是懸空指針。排查步驟我建議按這個順序來先確認(rèn)崩潰點(diǎn)對應(yīng)哪個對象的操作再看這個對象的內(nèi)存來自哪里堆、棧、靜態(tài)區(qū)它什么時候被釋放的然后用調(diào)試器查看該地址的調(diào)用棧和持有關(guān)系最后檢查所有與該對象相關(guān)的拷貝、賦值、移動操作確認(rèn)沒有共享堆內(nèi)存。7.3 在Visual Studio Code里配置C開發(fā)環(huán)境的一些額外提醒熱詞里還有“vscode配置c/c環(huán)境”和“vscode c”如果你已經(jīng)走到類和對象下篇大概率是已經(jīng)能在VS Code里跑單文件測試代碼了。不過有幾個細(xì)節(jié)容易讓學(xué)習(xí)體驗翻車第一調(diào)試時要把.vscode/launch.json里的program路徑和tasks.json里的輸出文件名對齊否則F5調(diào)試會報找不到可執(zhí)行文件。第二如果安裝了多套編譯器MinGW、WSL GCC、MSVC配置里容易互相干擾我建議一個工作區(qū)只綁定一個編譯器工具鏈新手最穩(wěn)的組合是MinGW-w64 C/C擴(kuò)展。另外在跑類相關(guān)的多文件示例時為每個測試單獨(dú)建一個可執(zhí)行目標(biāo)。比如你寫了一個String.hpp想在兩個cpp文件里分別測試不同功能最好創(chuàng)建兩個可執(zhí)行文件不要試圖在一個main函數(shù)里塞進(jìn)所有測試邏輯否則類名字沖突會把你煩死。7.4 動態(tài)內(nèi)存相關(guān)其他熱詞問題熱詞里有“microsoft visual c redistributable”和“visual c redistributable”這其實是很多Windows用戶運(yùn)行庫缺失的常見問題。如果你下載的C程序雙擊無反應(yīng)、啟動報錯0xc000007b或者找不到msvcp140.dll多半是缺少對應(yīng)版本的VC運(yùn)行庫。這和寫代碼沒有直接關(guān)系但學(xué)習(xí)C的人在環(huán)境搭建階段常常栽在這里。我的建議是不要裝一堆各種年份的版本去微軟官網(wǎng)安裝最新的Visual C 2015-2022 Redistributablex64和x86都裝一下絕大多數(shù)程序都能覆蓋。這個運(yùn)行庫是向后兼容的裝了新版本老程序通常也能用。8. 一段話總結(jié)我實操中的習(xí)慣說了這么多其實“C之類和對象下”整個板塊在我眼里的核心價值只有一個讓你親手構(gòu)建的類變得值得信賴?？截惪刂啤①Y源管理、運(yùn)算符重載、繼承多態(tài)這些不只是考點(diǎn)更是以后真正工程代碼的承重墻。我個人的習(xí)慣是每學(xué)完一個特性就在VS Code里寫一個30行以內(nèi)的最小復(fù)現(xiàn)程序故意去踩那些經(jīng)典的坑——淺拷貝、忘記虛析構(gòu)、在構(gòu)造函數(shù)里調(diào)虛函數(shù)——然后觀察報錯和內(nèi)存異常只有親眼見過這些崩潰才能真正記得住為什么需要那些規(guī)范。學(xué)習(xí)C沒有捷徑但每踩過一個坑后面代碼就穩(wěn)一分。你接下來每一天寫的每一個類都應(yīng)該比昨天那個更可靠。