C++中struct默认public继承和public成员，与class唯一区别仅在于默认访问控制和继承方式；二者语义一致，支持全部OOP特性且内存布局相同。
struct 在 C++ 中默认是 public 继承和 public 成员
这是最常被忽略的底层规则：C++ 的 struct 和 class 语义几乎完全一致，唯一强制区别只有默认访问控制和默认继承方式。
也就是说，下面两个定义等价：
struct S {
int x;
void f() { }
};
class C {
public:
int x;
void f() { }
};
但如果你显式写了 private: 或 public:，那 struct 和 class 就彻底没区别了——编译器不认关键字，只认你写的访问标号。
-
struct默认成员访问权限是public；class默认是private -
struct默认继承方式是public；class默认是private - 二者都支持构造函数、析构函数、虚函数、模板、友元、静态成员、继承、多态……所有 OOP 特性
- 内存布局完全相同（只要成员类型和顺序一致），可互相
reinterpret_cast（谨慎！）
什么时候该用 struct，什么时候该用 class
这不是语法问题，而是约定和意图表达问题。C++ 标准不强制，但主流项目（如 STL、Qt、Google C++ Style Guide）有清晰倾向：
立即学习“C++免费学习笔记（深入）”；
Work Productivity Gog Google Workflow Helper
下载
帮助用户满足已验证的需求：代理用户在Clawhub上对Gog式工作流有强烈需求，需要实际帮助修复bug、强化设置等。
- 用
struct表示“纯数据聚合”（POD 或接近 POD）：比如坐标Point { double x, y; }、配置项Config { int timeout; bool verbose; } - 用
class表示“封装行为+状态”的抽象类型：比如DatabaseConnection、ThreadPool - 哪怕
struct加了构造函数（如Point(double x, double y) : x(x), y(y) {}），只要没私有成员、没虚函数、没复杂生命周期管理，仍算“数据为主” - 一旦出现
private成员、protected接口、虚函数、自定义operator new，就该换用class——不是不能，而是信号混乱
struct 定义常见错误：忘了分号、混淆 C 风格声明
C++ 中 struct 定义末尾必须有分号，漏掉会报错，且错误位置可能误导（比如报在下一行）：
struct Vec2 {
float x, y;
}; // ← 这个分号不能少
另外，C 风格写法 typedef struct { ... } Name; 在 C++ 里完全多余，也容易出错：
- 错误写法：
typedef struct { int a; } MyStruct;→ 多余typedef，且MyStruct不是类型别名而是结构体标签名 - 正确写法（推荐）：
struct MyStruct { int a; };→ 直接可用MyStruct作类型名 - 如果真要别名，用
using：using MyStruct = struct { int a; };（但通常没必要）
struct 与 class 混用时的 ABI 和模板推导陷阱
虽然语言层面等价，但实际工程中混用可能埋坑：
- 某些 ABI（如 Itanium C++ ABI）对
struct和class的 name mangling 完全一致，但若有人手写符号名或做反射，可能依赖关键字字符串 - 模板参数推导不会因
struct/class关键字不同而失败，但若用到 SFINAE 判断“是否为 POD”，struct更可能满足（因为习惯上不加私有成员） - 头文件中若先声明
class Foo;，后定义struct Foo { ... };，会编译失败（前向声明和定义关键字必须一致） - Clang/GCC 对
struct成员初始化（如int x = 42;）的支持早于class（C++11 起两者都支持，但老代码可能有差异）
真正关键的不是语法能不能，而是团队能否通过关键字一眼判断“这东西是不是只存数据”。一旦这个信号失效，维护成本会上升——尤其在跨模块、跨语言绑定（如 Rust FFI）或序列化场景下，字段可见性比关键字本身重要得多。
