对象就是一块内存：从 C struct 到 C++ class

别急着把“对象”想复杂

刚学 C++ 的人，最容易被几个词一起吓住：对象、封装、构造、析构、面向对象。这些词一股脑儿压过来，很容易让人产生一种错觉——仿佛 C++ 里有一套脱离机器、悬在空中的神秘机制。

其实不用。

如果你愿意先把心放平一点，这一篇只讲一件事：对象，先是一块内存。

当然，这句话不能只说一半。如果只说“对象就是内存”，新人会觉得太糙，老手会嫌你偷懒。更完整一点的说法应该是：

一个 C++ 对象，首先会占一块内存；
类型告诉编译器该怎样解释这块内存；
而 class、构造、析构、访问控制这些语言机制，则是在这块内存周围补上规则和纪律。

你可以先把它想成一间房子。内存是地皮和墙体，类型是户型图，成员函数是这间房子允许你怎么使用它的说明书，private 是门锁，构造和析构则是在管“什么时候入住”“什么时候退租”“退租时谁负责把水电关掉”。

这个角度非常重要。因为你后面学 this、学继承、学虚函数、学对象切片、学 RAII，本质上都在回答同一类问题： 编译器究竟怎样把一段内存，变成一个有意义、能协作、还能自动守规矩的对象。

所以这一篇我们不急着喊口号，也不急着背“面向对象三大特性”。先把地基打牢。先回到那个比“对象”更早、也更老实的词：内存。

在 class 之前，程序员先学会给字节起名字

我最早学 C 的时候，老师不爱讲对象。他讲地址，讲指针，讲 malloc，讲数组和结构体，最后拍着黑板说：结构体就是一段连续的字节。

这句话第一次听，很多人会皱眉：太硬了吧，怎么一点都不“现代”。但你写久了会发现，这话虽然不漂亮，却非常诚实。

先看一个最朴素的结构体：

struct Point {
    int x;
    int y;
};

如果你现在写下：

Point p{3, 4};

那编译器首先要做的，不是思考“这是一个二维点的抽象概念”，而是先给 p 找一块足够大的内存。接下来，Point 这个类型再告诉编译器：

这块内存里的前一部分按 x 来解释；
后一部分按 y 来解释；
以后看到 p.x，就去这块内存里读 x 那个位置；
看到 p.y，就去读 y 那个位置。

如果你喜欢更直观一点的想法，可以先把它粗略地想成这样：

对象 p 的起始地址
┌────────────┬────────────┐
│     x      │     y      │
└────────────┴────────────┘

在很多常见平台上，如果 int 是 4 个字节，那么新手阶段你可以先把它近似理解成：

起始地址 + 0  -> x
起始地址 + 4  -> y

注意，我这里故意说“近似理解”。因为真实世界里还会有对齐和填充的问题，后面我们会专门讲：为什么有时候对象看着很瘦，sizeof 却比你想的大。但在第一遍建立直觉时，这个近似模型非常有用。先别一上来就被 ABI、padding、alignment 这些词吓住。先抓住大意：结构体让你能把一段原本匿名的字节，解释成有字段名、有读取方式的一块数据。

有一个小工具特别适合帮助建立这个直觉：

#include <cstddef>

static_assert(offsetof(Point, x) == 0);
static_assert(offsetof(Point, y) == sizeof(int));

这里的 offsetof 你可以先把它理解成“字段离对象起始地址有多远”。这个“有多远”，就是偏移量。如果把对象比作一排抽屉，偏移量就是“从第一个抽屉开始，走多少格才能走到某个字段”。

所以当你第一次看到“对象在内存里的布局”这几个字，先别想得太玄。它说的其实就是： 这块内存从哪里开始，里面的字段按什么顺序摆，每个字段从第几个字节开始读。

说到底，struct 最早解决的，不是优雅，而是秩序。它不是创造了新物质。它只是给字节起了名字，给布局添了解释。

而这，正是“对象”这条线索最早的起点。

C 程序员其实早就在“手写对象”

有了数据，下一步自然就是操作数据。在 C 里，最常见的做法是：数据放进 struct，操作写成外部函数。

比如你完全可以写出这样一组 API：

#include <cmath>

struct Point {
    int x;
    int y;
};

Point point_make(int x, int y) {
    Point p;
    p.x = x;
    p.y = y;
    return p;
}

void point_move(Point* p, int dx, int dy) {
    p->x += dx;
    p->y += dy;
}

double point_length(const Point* p) {
    return std::sqrt(double(p->x) * p->x + double(p->y) * p->y);
}

用起来是这样的：

Point p = point_make(3, 4);
point_move(&p, 1, 2);
double len = point_length(&p);

你看，这里面已经有很强的“对象味”了。 Point 负责存数据，point_move、point_length 负责操作这份数据。只是 C 不会替你说“这是一个对象”，它只会很老实地告诉你：这是一份结构体数据，再配几组相关函数。

很多初学者是先学 C++，后回头看 C，于是会误以为： “C 只有数据，没有对象；C++ 突然发明了对象。”

其实不是。

C 程序员很早就在手写对象了。他们会写 file_open、file_close、file_read；会写 list_init、list_push、list_pop；会用同一个前缀，把一类数据和一组操作绑在命名上。

你去看很多老牌 C 库，甚至今天还在大量使用的底层系统代码，都还能闻到这种味道。语言没有替你把它包装成 obj.method() 的形式，但工程上的意图已经非常明确：这些函数，就是围着这份数据转的。

这一步非常值得看懂。因为它会帮你拆掉一个错觉：所谓“对象”，并不是从天而降的新物种。很多时候，它只是把程序员原本手工维持的关系，正式交给语言来认领。

但问题也正出在“手工维持”这四个字上。

项目小时候，靠约定问题不大。名字起得规范一点，接口写清楚一点，大家彼此心里有数。可项目一大，事情就开始变得微妙。字段谁都能改，状态谁都能碰，资源谁申请谁释放全靠自觉，错误路径靠文档和评审补洞。

这也是为什么老一代系统程序员一边嘴上嫌弃“花里胡哨的抽象”，一边又会慢慢接受 C++ 的某些做法。不是因为他们突然迷上了哲学。而是因为他们太清楚：有些纪律，交给人记，不如交给语言管。

这条路不是凭空来的：C 给了地基，Simula 给了灵感，Smalltalk 走了另一条路

说到这里，就该补一段历史了。不然“为什么后来会有 class”这件事，读起来总像是半路插进来的新玩意儿。

如果按发展脉络看，C++ 并不是一门突然冒出来的“全新对象语言”。它更像是几股传统在 1970 年代末、1980 年代初碰到一起之后，长出来的一种工程折中。

先说 C。

C 的强项特别鲜明：离机器近，代价可见，布局可控。你定义什么数据，大体就能猜到会占多少内存；你传指针、改字段、调用函数，心里有账。这对系统编程来说太重要了。写编译器、写操作系统、写网络软件，你不可能完全不在乎对象最后落成什么样。

再说 Simula。

Simula 是 1960 年代的语言，最有名的历史地位之一，就是它被广泛看作最早的面向对象语言源头。它提出的那套“类、对象、继承、把数据和行为放在一起”的想法，对后来的语言影响极大。如果你站在“建模”的角度看，Simula 的味道很浓：现实世界有船、有港口、有顾客、有事件，于是程序里也有对应的对象和关系。

Stroustrup 后来自己就公开说过，C++ 的很多关键想法是从 Simula 借来的。这话很重要，因为它把历史说清楚了：C++ 不是先发明对象、再硬塞给 C；它是把 Simula 那套表达力，试着搬到一个更贴近系统编程的世界里。

那 Smalltalk 呢？

Smalltalk 也很重要，而且它也继承了 Simula 那条血脉。但它走得更彻底。它更强调“万物皆对象”、消息传递、强运行时、动态系统。如果你把 Simula、Smalltalk、C++ 放在一起看，可以粗略地这么理解：

Simula 给的是“类和对象这套思维骨架”；
Smalltalk 把这套骨架发展成一个更纯粹、更动态的对象世界；
C++ 则没有走“纯对象宇宙”那条路，而是坚持把脚留在 C 的地面上。

这恰恰是 C++ 最有意思、也最经常被误解的地方。它不是在追求“最纯的对象哲学”。它在追求的是另一件事：既想借到对象的组织能力，又不想丢掉 C 的效率、布局感和成本可预测性。

所以你才会看到一个很有意思的横向对比：

在 C 里，程序员习惯写：

point_move(&p, 1, 2);

在更“纯对象”的思路里，重点往往是“给对象发一条消息”。

而在 C++ 里，你写：

p.move(1, 2);

表面上看，它像是更高级的对象表达。但它背后从来没有忘记一件事：这个调用最终还是要落到可预测的机器模型上。

你可以把 C++ 看成一场很典型的工程妥协。它借了 Simula 的 class 思想，却没有照搬 Smalltalk 那种重运行时、重消息派发的路线。它更像是在说：

“我想要抽象，但这个抽象必须付得起账。”

Stroustrup 后来有一句很著名的话，大意就是：一个语言特性不只要有用，还得付得起代价。 这句话放在对象模型里尤其关键。它解释了为什么 C++ 里的对象从来不是飘在空中的概念，而总是和布局、调用成本、生命周期这些问题绑在一起。

`C with Classes`：不是推翻 C，而是把手工套路正式收编

1979 年，Stroustrup 在贝尔实验室开始做的那个东西，名字就很直白：C with Classes。

你可以从这个名字里直接读出它的野心和克制。它不是“告别 C”。它是“在 C 上面长出 class”。

这个出发点很朴素，却几乎决定了后来 C++ 对象模型的整体气质。早期的 C++ 编译器 cfront，甚至会把 C++ 代码先翻译成 C，再交给 C 编译器继续处理。 Stroustrup 后来回忆这段历史时，甚至说过一句很传神的话：cfront 输出 C，但并不是拿 C 来帮忙做语义检查，它更像是“把 C 当汇编器来用”。

这句话你要是第一次看到，可能会觉得有点夸张。其实一点都不夸张。它传达的是一个非常关键的事实：

C++ 的很多高级写法，在底层必须能落回 C 也能表达的那些基本材料：结构体、函数、指针、布局、调用。

比如我们把前面的 Point 换成 C++ 写法：

struct Point {
    int x;
    int y;

    void move(int dx, int dy) {
        x += dx;
        y += dy;
    }

    double length() const {
        return std::sqrt(double(x) * x + double(y) * y);
    }
};

你看到的是：

p.move(1, 2);
double len = p.length();

但为了帮助理解，你完全可以先在脑子里把它翻译成更朴素的样子：

Point_move(&p, 1, 2);
double len = Point_length(&p);

这当然不是标准规定的“源码展开形式”。编译器真实实现会复杂得多。但在入门阶段，这个理解模型非常好用。

它一下子解释了三个新手常见困惑：

第一，成员函数为什么知道自己在操作哪个对象？ 因为调用时会有一个隐藏的对象地址传进去，这个隐藏参数就是 this。

第二，成员函数是不是也住在对象里面？ 通常不是。对象里主要装的是数据成员；成员函数的代码本体在代码段里，所有对象共享同一份函数实现。

第三，为什么我给类多写几个普通成员函数，sizeof 往往不变？ 因为普通成员函数一般不会作为“每个对象各存一份”的内容放进对象里。你多写两个函数，通常只是多了代码，不会让每个对象都跟着变胖。

看一个最小例子：

struct Counter {
    int value;

    void inc() { ++value; }
    void reset() { value = 0; }
};

这里你可以先这样理解：

Counter 对象里真正需要存的，是 value 这份状态；
inc() 和 reset() 是“对这份状态能做什么”的规则；
每次调用时，编译器把“当前对象是谁”通过 this 传进去。

所以我一直觉得，成员函数最值得新手理解的地方，不是“它很高级”，而是“它把原本散落在外面的函数，拉回了数据旁边”。

这一步的意义并不神秘。它只是把人本来就会手工维护的一种关系，正式写进了语言。

`struct` 和 `class` 在标准里只差一点，在工程上却差很多

学到这里，很多人会问一个非常合理的问题：既然 struct 也能有成员函数，class 也能放数据，那它们到底差在哪？

如果从标准条文上说，差别真的不大。

struct S {
    int x;
};

class C {
    int x;
};

这里最核心的区别只是默认访问权限不同： struct 的成员默认是 public，class 默认是 private。继承默认权限也是同样的差别。

就语言表面而言，这点差别简直小得像个玩笑。可一旦进了真实工程，它的意义就会突然放大。

因为真正重要的，从来不只是“能不能访问”。真正重要的是：你是把这块内存当作公开记录，还是当作带约束的抽象来维护。

很多新手刚听到封装，会误以为那是一种“面向对象的礼节”。好像 private 只是为了显得更优雅、更学院派。

不是。

private 最硬核的价值，根本不是优雅，而是把修改成本显式化。

先看一个完全公开的数据结构：

struct Percent {
    int value;
};

这写法最大的好处是直接。谁看见都知道里面有个 value，谁都能改。

但问题也正出在“谁都能改”。如果你心里真正想表达的是“百分比必须始终落在 0 到 100 之间”，那这个结构体根本没把这个要求写进代码。它只是把愿望放在了程序员脑子里。

于是你就很容易写出这样的代码：

Percent p{150};
p.value = -20;

编译器不会拦你。因为从它的角度看，这只是给一个 int 赋值而已。

那怎么办？你可以在 C 里继续靠约定，多写几层函数：

struct Percent {
    int value;
};

void percent_set(Percent* p, int v) {
    if (v < 0) v = 0;
    if (v > 100) v = 100;
    p->value = v;
}

这当然能工作。但它的问题还是一样：只要别人绕开 percent_set()，你的规则就失效了。

这时候 class 的意义就出来了：

class Percent {
public:
    explicit Percent(int v) {
        if (v < 0) v = 0;
        if (v > 100) v = 100;
        value_ = v;
    }

    int value() const { return value_; }

private:
    int value_;
};

这里最值得你记住的，不是 private 这几个字母本身，而是一个非常重要的概念：不变量。

所谓不变量，你可以先把它理解成：一个对象在任何时刻都应该满足的条件。

在这个例子里，不变量就是： Percent 的值应该始终在 0~100 之间。

一旦你把字段藏起来，让外部只能通过构造函数和公开接口接触它，编译器就开始替你守门了。这时封装不再是一句口号，而是一条真正能落地的工程规则。

所以如果你问我，struct 和 class 在工程里的气质差别到底是什么，我会这样总结：

struct 更像是“公开的数据记录”。它适合那种字段本来就应该被自由读取、自由组合的数据。

class 更像是“带约束的数据抽象”。它适合那种你希望外界通过规则而不是通过裸字段来操作的数据。

语言层面的差别很小。工程层面的差别很大。

这也是很多团队后来越来越偏爱 private 的原因。不是因为大家突然变文艺了。而是因为代码一大、协作一多，靠人肉守边界这件事，迟早会漏风。

真正把 C++ 拉开差距的，不只是封装，而是生命周期

如果故事只讲到 private，那 C++ 还只是“更会组织代码的 C”。它真正拉开差距的地方，是又往前走了一步：它开始把“时间”也写进对象。

这句话第一次听也许会有点抽象，我们先用一个非常现实的场景来拆。

假设你在 C 里处理文件：

FILE* f = fopen("data.txt", "r");
if (!f) {
    return;
}

// 读文件
if (some_error()) {
    return;  // 糟了，这里忘了 fclose(f)
}

fclose(f);

这个例子不高级，甚至有点土。可它特别真实。

新手最常把“资源”理解成内存，于是觉得资源泄漏就是 malloc 了没 free。其实不是。文件句柄、socket、锁、数据库连接，甚至某些临时打开的系统状态，统统都算资源。

这些东西有一个共同点： 拿到它们时要记账，用完之后要归还。

而 C 语言对这件事的处理方式，通常是手工配对：

open 对 close
init 对 destroy
lock 对 unlock

这套办法很诚实，也很脆弱。流程一简单，问题不大；流程一复杂，函数里开始出现多个 return、多个错误分支，你就会越来越依赖 goto cleanup 这种收尾模式。

很多没写过系统代码的人，一看 goto cleanup 就本能皱眉。其实你得替老 C 程序员说句公道话：这往往不是风格粗糙，而是他们在用最少的语言机制，硬撑住资源释放的秩序。

真正高明的是 C++ 后来做的那一步。它不是简单地说“请大家更小心一点”。它是把资源释放这件事，直接绑到对象生命周期上。

比如：

class File {
public:
    explicit File(FILE* f) : f_(f) {}

    ~File() {
        if (f_) {
            fclose(f_);
        }
    }

    FILE* get() const { return f_; }

private:
    FILE* f_ = nullptr;
};

然后你可以这么写：

File file(fopen("data.txt", "r"));
if (!file.get()) {
    return;
}

// 使用文件
if (some_error()) {
    return;  // 这里提前 return，也会自动调用析构
}

这里的关键，不是“析构函数听上去很高级”。关键是：资源释放从“程序员记得做”变成了“作用域结束时自动做”。

这就是 RAII。

这个缩写第一次看到很容易头大，先别急着背全名。你可以先用一句很土但很好记的话理解它：

资源跟对象绑在一起。对象出生时拿资源，对象离开作用域时还资源。

等这个直觉稳了，你再记全名也不迟：Resource Acquisition Is Initialization，资源获取即初始化。

为什么这件事在 C++ 里这么核心？因为对象从这一刻开始，不只是在描述“空间上的布局”，还开始接管“时间上的纪律”。

class 和 private 管的是：这块内存能被谁碰，按什么规则碰。

RAII 管的是：这块内存相关的资源什么时候拿到，什么时候自动收尾。

这才是 C++ 真正厉害、也最容易让老手点头的地方。

Stroustrup 后来回忆语言演化时提到过一件很有意思的事：确定性析构在 1979 年最早的 C with Classes 里就已经出现了；而异常机制是后来才加进来的，他甚至因为 RAII 这个思路没想透，一度把异常的引入往后推了半年。

这段小历史很能说明问题。 RAII 并不是后来某个爱写设计模式的人拍脑门想出来的“优雅技巧”。它是 C++ 这门语言在面对真实工程问题——尤其是错误路径和资源管理问题——时长出来的核心能力。

你要是写过这种 C 代码：

void old_fct(const char* name) {
    FILE* f = fopen(name, "r");
    if (!f) return;

    // ... 中间一堆处理
    if (some_error()) return;

    fclose(f);
}

再看这种 C++ 写法：

void new_fct(const char* name) {
    File file(fopen(name, "r"));
    if (!file.get()) return;

    // ... 中间一堆处理
    if (some_error()) return;
}

你马上就能明白，为什么那么多真正做工程的人会喜欢 RAII。它不是浪漫。它是省事故。

而且别忘了，资源并不只是一根文件指针。内存、锁、文件、socket，这些都可以套进同一套思路里。这也是为什么 C++ 很少把“资源管理”单独看成一个边角课题。在它的对象模型里，资源管理就是对象语义本身的一部分。

横着看一眼，你会更明白 C++ 到底在做什么

学语言时，一个常见误区是只在语言内部打转。今天学 struct，明天学 class，后天学构造析构，好像都是零散语法点。其实你把几门语言横着摆一摆，很多事会一下子变清楚。

如果只看“数据和操作怎么组织”，可以先粗略地这么看：

在 C 里，典型做法是“结构体 + 外部函数”。你靠命名、靠文档、靠团队习惯，把相关数据和操作归在一起。优点是直白，开销看得见；缺点是边界靠人守。

在 Simula 那条思路里，语言开始正面承认：数据和行为本来就应该一起被建模。于是 class、object、inheritance 这种概念被明确提出来。优点是表达力强；缺点是它并不是从系统编程和贴近硬件的需求出发长出来的。

在 Smalltalk 那条路上，对象观念走得更彻底。消息传递、动态系统、运行时能力都更强。它像是在告诉你：“别总盯着底层布局，先把整个对象世界搭起来。”

而 C++ 的选择很特别。它没有否认 C 的地基，也没有拒绝 Simula 的灵感。它更像是两边都没完全背叛。

你可以把它理解成这样：

它向 C 学了对机器的诚实；
向 Simula 学了 class、继承、多态这些组织方式；
却没有完全走向 Smalltalk 那种更纯粹、更依赖运行时的对象世界。

所以 C++ 的对象才会有一种很独特的气质：它既不是赤裸裸的“只有字节和指针”，也不是完全不关心布局和代价的“纯对象宇宙”。它是站在中间那条很难、但也很实用的线上：

我要抽象，但我得知道抽象最后是怎么落地的。

这个判断，一旦立住了，后面很多东西你都会看得更顺。比如为什么 C++ 允许你写高层抽象，却总在关键处把底层模型露出来；为什么它的对象模型老和布局、指针、vptr、构造顺序这些实现细节缠在一起；为什么它既能写“像 C 的代码”，也能写“很像对象系统的代码”。

因为它从诞生那天起，就不是在押注单一哲学。它是在做平衡。

回到开头：对象到底是什么

现在我们把前面的线索重新收一遍。

如果你只盯着语法，看到的是： struct、class、成员函数、private、构造、析构。

但如果你顺着历史和实现往下看，你会发现事情其实非常连贯。

最开始，程序员只是需要一种办法，给一段相关字节起名字，于是有了 struct。后来他们又需要把一组操作和这段数据绑得更紧，于是开始写一批带前缀的外部函数，手工维持“这组函数就是操作这份数据”的关系。再后来，C++ 把这种关系正式收编进语言里，于是成员函数来了，this 来了，obj.f() 这种写法来了。事情再往前走一步，工程里开始越来越在意“谁可以改这块内存、改的时候要守什么规则”，于是访问控制、封装、不变量这些概念开始变得重要。最后，大家发现真正难的还不只是“空间上怎么摆”，更是“时间上怎么收尾”，于是构造、析构、RAII 让对象开始负责资源和生命周期。

你看，这其实不是一堆零碎特性。它是一条非常完整的演化线：

从“给字节起名字”，到“把操作挪到数据旁边”，再到“把规则和生命周期绑回这块内存”。

所以这篇文章如果你只带走一句话，我希望是这句：

C++ 对象，先是内存；
类型决定这块内存该怎样被解释；
class、private、构造、析构，则是在这块内存周围立起规则、边界和时间秩序。

这句话一旦真懂了，后面很多知识就不会再是孤零零的结论。

你再学拷贝和移动，会想到：复制的不只是字节，往往还牵涉这份对象合同该怎么延续。

你再学虚函数，会想到：为了让“同一接口，不同实现”跑起来，编译器到底在对象里偷偷加了什么账单。

你再学对象切片，会想到：当派生类对象按值拷进基类对象时，究竟是哪块内存留下来了，哪块被切掉了。

这就是对象模型的意义。它不是为了把代码写得更玄。恰恰相反，它是为了让你在面对那些看似高级的 C++ 语法时，心里一直有一幅不慌的底图。

那幅底图就是：对象没有魔法，先看内存；再看规则；最后看生命周期。

下一篇，我们就继续顺着这张底图往下挖。既然对象先是一块内存，那为什么 sizeof 经常比你想的大？为什么一个看起来只有几个字段的对象，会被对齐和填充悄悄撑胖？把这个问题弄明白，你对“对象到底长什么样”的直觉，就又会往前迈一大步。