1. 模板参数的本质：struct与class的深层解析
在C++模板编程中，struct和class作为模板参数时究竟有何区别？这个问题困扰着许多刚接触系统级开发的工程师。让我们从编译器视角彻底剖析这个看似简单却内涵丰富的话题。
1.1 模板参数的类型接纳机制
模板参数的核心要求是类型完整性，而非声明方式。当编译器看到template<typename T>时，它只关心T类型是否满足以下基本条件：
- 是否是一个完整的类型（complete type）
- 是否提供了模板实例化所需的成员和方法
- 是否符合C++的类型系统规则
cpp复制// 典型模板类定义
template<typename DeviceType>
class DeviceController {
DeviceType mDevice; // 只关心DeviceType是否有需要的接口
public:
void initialize() {
mDevice.connect(); // 只要DeviceType有connect()方法即可
}
};
关键理解：模板参数的类型标签（struct/class）对编译器而言只是语法糖，真正重要的是类型本身的属性和能力。就像USB接口只关心设备是否符合协议标准，而不管设备外壳是塑料还是金属。
1.2 Android Camera框架的典型应用
在Android Camera HAL层的实现中，这种设计模式被广泛应用。以CameraDeviceClientBase为例：
cpp复制struct CameraDeviceClientBase :
public CameraService::BasicClient,
public hardware::camera2::BnCameraDeviceUser {
// 默认public访问权限
status_t initialize(sp<ProviderType> provider);
protected:
sp<ICameraDeviceCallbacks> mRemoteCallback;
};
此处选择struct而非class的深层考量包括：
- 接口显式性：作为基础接口集合，需要明确暴露所有方法给模板类
- 继承透明性：多重继承时默认public继承更符合接口定义需求
- 代码简洁性：减少public关键字的使用，提升可读性
2. 语法差异的底层原理
2.1 内存布局一致性验证
通过Clang生成的LLVM IR可以直观看到，struct和class在底层表示上完全一致：
llvm复制; struct示例
%struct.Point = type { i32, i32 }
; class示例
%class.Coord = type { i32, i32 }
; 函数使用
define void @usePoint(%struct.Point* %p) {
%x = getelementptr %struct.Point, %struct.Point* %p, i32 0, i32 0
store i32 10, i32* %x
ret void
}
define void @useCoord(%class.Coord* %c) {
%x = getelementptr %class.Coord, %class.Coord* %c, i32 0, i32 0
store i32 20, i32* %x
ret void
}
关键观察点：
- 类型签名只有名称差异
- 成员访问方式完全相同
- 内存对齐规则一致
2.2 符号修饰(name mangling)对比
C++编译器对struct和class的类型签名处理也完全一致：
cpp复制struct S { void foo(); };
class C { void bar(); };
// 使用g++ -S查看汇编输出
// S::foo()的符号：_ZN1S3fooEv
// C::bar()的符号：_ZN1C3barEv
修饰规则完全遵循相同的Itanium C++ ABI规范，进一步证明它们在ABI层面没有区别。
3. 工程实践中的选择策略
3.1 系统级开发的惯例用法
在Android、Chromium等大型C++项目中，开发者形成了特定的使用惯例：
| 场景 | 推荐选择 | 典型示例 | 理由 |
|---|---|---|---|
| 纯接口定义 | struct | IBinder.h中的接口类 | 强调方法公开性，避免忘记写public |
| 模板元编程 | struct | type_traits实现 | 传统惯例，Boost/STL都采用此风格 |
| 有状态对象 | class | android::CameraDevice | 需要封装内部状态和复杂行为 |
| POD数据类型 | struct | gralloc_handle_t | 保持C兼容性，明确表示简单数据聚合 |
| CRTP模式中的基类 | struct | enable_shared_from_this | 方便派生类访问基类成员 |
3.2 模板参数设计的最佳实践
当设计要被用作模板参数的类型时，建议遵循以下原则：
-
访问控制显式化：
cpp复制struct TemplateParam { public: // 即使struct也显式声明 void requiredMethod(); private: void internalHelper(); }; -
接口文档化：
cpp复制/** * 模板类型T必须提供以下方法： * - connect(): 建立设备连接 * - send(data): 发送字节数据 * - isReady(): 返回bool状态 */ template<typename T> class DeviceAdapter; -
静态断言检查：
cpp复制template<typename T> class CameraHal { static_assert(std::is_base_of_v<CameraBase, T>, "T必须继承自CameraBase"); };
4. 复杂场景下的特殊考量
4.1 模板特化中的差异处理
虽然一般情况下struct和class可互换，但在模板特化时可能需要区分：
cpp复制template<typename T> struct is_class : false_type {};
template<typename T> struct is_class<class T> : true_type {}; // 只匹配class关键字
// 使用示例
static_assert(!is_class<struct S>::value, ""); // 可能在某些编译器中成立
不过这种用法非常罕见，现代编译器通常将两者等同对待。
4.2 前向声明的影响
前向声明时使用的关键字会影响代码可读性：
cpp复制class ForwardDeclared; // 暗示后续有复杂定义
struct SimpleRecord; // 暗示可能是POD类型
// 但实际定义时可以改变：
class SimpleRecord { int x; }; // 虽然用class但实际简单
struct ForwardDeclared { virtual ~ForwardDeclared(); }; // 虽然用struct但有虚函数
5. 性能与二进制兼容性
5.1 运行时性能零差异
通过对比测试可以验证性能一致性：
cpp复制struct S { int a; void foo() { a++; } };
class C { int b; void bar() { b++; } };
// 编译优化后生成的汇编代码完全相同：
// mov eax, DWORD PTR [rdi]
// add eax, 1
// mov DWORD PTR [rdi], eax
// ret
5.2 ABI兼容性注意事项
在与C语言交互时需要注意：
| 场景 | 处理方案 | 示例 |
|---|---|---|
| C++ struct传递给C函数 | 需确保是标准布局类型 | extern "C" void process(struct PlainData*); |
| 包含虚函数的类型 | 必须用class声明 | 虚函数表会使类型成为非标准布局 |
| 跨动态库边界传递 | 显式指定可见性 | struct __attribute__((visibility("default"))) SharedType { ... }; |
6. 现代C++的演进趋势
6.1 结构化绑定的支持
C++17引入的结构化绑定对struct有特殊优化：
cpp复制struct Point { int x; int y; };
auto [x, y] = Point{1, 2}; // 直接解构
// 对class则需要满足特定条件
class Coord {
public:
int a, b;
};
auto [u, v] = Coord{}; // 同样可以，但强调数据成员需public
6.2 概念(Concepts)的约束
C++20的概念可以统一约束模板参数：
cpp复制template<typename T>
concept CameraInterface = requires(T t) {
{ t.initialize() } -> std::same_as<status_t>;
{ t.submitRequest(const CameraRequest&) } -> std::convertible_to<int>;
};
// 使用时不再关心struct/class
template<CameraInterface T>
class CameraHalImpl;
7. 实际项目中的决策流程图
当面临struct/class选择时，可参考以下决策路径：
code复制开始
│
├─ 需要与C代码交互？ → 使用struct
│
├─ 是纯接口定义？ → 优先struct
│
├─ 包含复杂私有状态？ → 使用class
│
├─ 用于模板元编程？ → 传统用struct
│
└─ 其他情况 → 根据团队规范选择
在Android Camera框架的具体实现中，这种选择体现得尤为明显。例如在CameraProviderManager.h中：
cpp复制// 硬件接口描述 - 使用struct强调公开性
struct ProviderInfo {
std::string providerName;
sp<ICameraProvider> interface;
status_t initialize();
};
// 服务实现类 - 使用class强调封装
class CameraProviderManager : public BnCameraProviderManager {
private:
std::mutex mLock;
std::vector<ProviderInfo> mProviders;
};
这种差异化的使用方式，既保证了接口的清晰可见，又确保了实现细节的适当隐藏，是大型C++项目中值得借鉴的设计模式。