C++ 安全性 / 安全漏洞分类（Safety/Security and C++）
MITRE CWE（Common Weaknesses Enumeration）
- CWE 是 MITRE 提出的 通用弱点枚举，用于系统化描述软件中的安全漏洞类型。
- 下面列出排名前 25 的常见弱点，重点涉及 C/C++ 开发中常见的安全问题。
排名前 25 的 CWE
总结
- C/C++ 中最常见的安全漏洞多与 内存管理、输入验证 和 权限控制 有关。
- 典型漏洞类型包括：
- 内存错误：越界读写、空指针解引用、释放后使用。
- 注入类漏洞：SQL 注入、命令注入、代码注入。
- 认证/授权问题：缺少认证、授权错误、硬编码凭据。
- 并发问题：竞态条件。
- 对 C++ 开发者而言，关注 CWE 高危漏洞列表，可以有效提升代码安全性。
医疗设备故障分析（Medical Device Failures Analysis）
风险分类
- Class I：高风险（high risk）
- Class II：中风险（medium risk）
- Class III：低风险（low risk）
召回总数及分类统计
可以用 LaTeX 表示总计比例公式：
重要发现
- 软件问题是医疗设备召回的主要原因：占比 ，连续九个季度位居首位。
- 说明：
- 本研究 不包含与安全性相关的召回。
- 软件缺陷对医疗设备可靠性影响最大，尤其在高风险和中风险类别中尤为突出。
总结
- **高风险召回（Class I）**中软件占比最大（33.3%）。
- **中风险召回（Class II）**中软件问题占绝大多数（65.6%）。
- **低风险召回（Class III）**中软件依然占比最高（75.3%）。
- 硬件、电池、I/O 等问题占比相对较低。
- 强调 软件质量控制 对医疗设备安全至关重要。
IEC 62304 是医疗器械软件开发的国际标准，强调 功能安全（Functional Safety） 和 软件风险管理（Software Risk Management）。标准的核心目标是确保软件在医疗器械中是安全、可靠、可控的。
- 软件开发规划（Software Development Planning）
- 需求分析（Software Requirements Analysis）
- 功能规格说明（Functional Specification）
- 架构设计（Architectural Design）
- 模块设计与实现（Software Unit Design & Implementation）
- 单元测试（Unit Testing）
- 集成与系统验证（Integration & System Verification）
- 发布（Software Release）
- 问题管理（Problem Resolution）
IEC 62304 根据软件可能导致的伤害严重性，将医疗软件分为 Class A, B, C：
- Class A：软件故障不会导致伤害
- Class B：软件故障可能导致非严重伤害
- Class C：软件故障可能导致严重伤害或死亡
风险评估流程
判断软件安全等级的逻辑：
- 软件故障是否会引发危险情况（hazardous situation）？
- 如果 否 → Class A
- 如果 是 → 继续评估
- 软件之外的风险控制措施是否足够有效？
- 如果 足够有效 → 可能降低软件类别
- 如果 不够有效 → 继续评估
- 软件故障可能导致的伤害严重性：
- 严重伤害/死亡 → Class C
- 非严重伤害 → Class B
用数学形式表示：
设软件故障导致危险的概率为 ，软件外部风险控制措施降低风险的效果为 ，伤害严重性为 ，则：具体判定逻辑可表示为：
注意：IEC 62304 还强调 软件配置管理（Software Configuration Management） 与 问题解决（Software Problem Resolution） 的持续管理。
- IEC 62304 强调 功能安全 和 软件风险管理。
- 软件风险等级（Class A/B/C）与 软件故障导致的伤害严重性 相关。
- 软件开发遵循严格的 分层、可验证、可追踪 流程。
- 数学化表示风险等级有助于量化和标准化软件安全分类。
IEC 62304 不仅关注软件开发阶段，还要求对 生产及后期使用阶段的软件风险进行管理和控制。
风险管理流程通常包括以下 6 个步骤：
- 风险分析（Risk Analysis）
- 确定软件可能导致的危险情况及潜在风险。
- 风险评估（Risk Evaluations）
- 评估风险发生的概率 和伤害严重性 。
- 风险控制（Risk Control）
- 针对已识别的风险采取措施降低风险。
- 风险管理报告（Risk Management Report）
- 总结风险分析、评估和控制措施。
- 整体剩余风险可接受性评估（Evaluation of Overall Residual Risk Acceptability）
- 判断剩余风险是否可接受。
- 生产与后期信息（Production and Post-Production Information）
- 持续收集使用中信息，更新风险管理。
软件风险可以用 概率-严重性模型表示：
设软件风险 的发生概率为 ，伤害严重性为 ，风险控制措施降低风险的效果为 ，则：
其中：
- ：剩余风险
- ：风险控制有效性， 表示完全消除风险
- ：伤害严重性（例如：非严重=1，严重=10，死亡=100）
剩余风险是否可接受：
如果不满足，则需要改进风险控制措施。
- IEC 62304 强调软件生命周期的 全程风险管理，包括开发、生产和后期监控。
- 常见的软件风险包括：内存泄漏、死锁、重入性问题、栈溢出、逻辑错误、无限循环、代码损坏、死代码等。
- 风险控制措施多样化，包括 设计策略、工具分析、运行时保护、测试验证。
- 数学模型帮助量化风险和控制措施效果，实现可验证的风险管理。
在 IEC 62304 标准下，医疗器械软件不仅包括自研软件，还可能依赖 第三方软件或开源组件，这些通常被称为 SOUP（Software of Unknown Provenance）。
定义：来源未知的软件组件，包括第三方库、开源软件或操作系统组件。
常见例子：
- 第三方库：Boost, Qt 等
- 操作系统或驱动：如 Fast OS、显示驱动
- 编译器本身也需要验证
SOUP 风险管理要求：
- 文档化（Documented）
- 组件来源、版本号、作者、许可证信息等。
- 验证与确认（Validated / Verified / Tested）
- 尽可能确认功能正确性与安全性。
- 软件依赖管理
- 使用 SBOM（Software Bill of Materials） 来列出依赖和版本信息。
SBOM 是一种 软件清单，用于管理和追踪软件组件：
- 内容：
- 组件名称（Name）
- 版本号（Version Strings）
- 作者（Author Name）
- 许可证（Licenses）
- 供应商信息（Supplier Name）
- 用途：
- 漏洞管理（Vulnerability Management）
- 合规性与报告（Compliance & Reporting）
- 供应链透明性（Supply Chain Transparency）
CBOM 是在 SBOM 基础上的安全扩展：
- 内容：
- 包含 SBOM 的全部信息
- 增加网络安全相关条目（如加密库、认证组件）
- 特点：
- 在很多场景下可与 SBOM 互换
- 用于支持医疗器械网络安全合规性要求
以 Cool Product 软件系统为例：
Cool Product Inc. 自研软件（IEC 62304 合规）
│
├─ Open source 数学库（SOUP）
├─ 操作系统（Fast OS 或其他OTS）
└─ 显示驱动（SOUP）
- 依赖关系：软件系统由多个组件和库构成，其中 SOUP 组件可能引入未知风险。
- 管理方式：
- 对每个依赖记录 SBOM/CBOM
- 验证功能、许可证、供应商信息
数学化表示：
设 Cool Product 软件系统的组件集合为 ，其中 SOUP 子集为 。则：其中 表示组件 的残余风险，对于 SOUP 组件：
- IEC 62304 是通用、高层标准，其特点：
- 高度概括、缺乏具体可执行性
- 多数只是推荐性条款，无强制性语言
- 潜在问题：
- 可用性与人体工程学（usability & human factors）
- 需求与系统设计错误
- 组件或系统间的非线性/间接交互
- 对复杂系统的需求增长可能超过质量标准
- 比较：
- 医疗器械标准可能比汽车（automotive）或航空（avionic）标准限制性低
- SOUP 组件需特别关注来源和验证，否则可能引入未知风险。
- SBOM 提供软件清单和依赖管理的可追踪机制。
- CBOM 在 SBOM 基础上增加网络安全信息。
- 依赖管理和风险量化可以用数学模型表示总风险：
- 合规性不足以保证安全，仍需考虑可用性、交互效应和复杂系统风险。
- 调查针对嵌入式系统产品。
- 约 2/3 的产品面向以下行业：
- 医疗（Medical）
- 国防（Defense）
- 汽车（Automotive）
- 工业技术（Industrial technologies）
这些领域对 安全性（Safety） 和 安全性+可靠性（Security & Reliability） 要求非常高。
- 功能正确性（Functional Correctness）
- 软件满足所有规格和需求（Specifications & Requirements）。
- 数学化表示：设软件功能集合为 ，输入集合为 ，输出为 ，则功能正确性要求：
- 功能安全（Functional Safety）
- 软件在任何情况下（包括故障场景）都不会产生意外行为（Unintended Behavior）。
- 医疗设备在输入响应时能正确操作，并防止患者伤害或危险。
- 常用 失效安全设计（Fail-safe Design）。
- 数学化表示残余风险 在功能安全下需满足：
- 安全性（Security）
- 系统、网络及数据免受未经授权访问、攻击、破坏或窃取。
- 保护目标包括：机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）。
- 用数学模型可表示为：设攻击事件集合为 ，系统被攻击成功概率为 ，则安全性要求：
- 实践差距明显：
- 很多嵌入式产品虽然应用于高风险行业，却缺乏基本的软件工程实践。
- 例如：静态分析、同行评审、回归测试缺失，增加了 功能错误（Functional Errors） 和 潜在危害（Hazards） 的风险。
- 安全与功能安全是不同概念：
- 功能正确性关注 需求是否实现。
- 功能安全关注 系统在故障或异常场景下是否安全。
- 安全性关注 抵御恶意攻击。
- 公式化总结：
设总风险 包括功能错误风险 、安全风险 和功能安全风险 ，则： - 对应调查中未遵循标准或忽略安全设计的团队，其 与 会显著上升。
- 高风险嵌入式系统（医疗、国防、汽车、工业）中，软件安全与功能安全缺口依然很大。
- 功能正确性、功能安全和安全性是三个不同层次，但都必须同时满足。
- 书面标准、静态分析、同行评审和回归测试等基本实践对降低风险至关重要。
- 数学化模型可以帮助量化风险、评估安全措施的有效性。
我们的使用案例是 Class-C 医疗设备，即 软件故障可能导致严重伤害或死亡 的医疗器械。
系统特点：
- 高度分布式机器人机电系统（Highly Distributed Robotic Electromechanical System）
- 超过 60 自由度（DoF, Degrees of Freedom）
- 软件复杂性高
- 数百万行 C++ 代码
- 多个领域和模块同时工作：实时（RT, Real-Time）、非实时（NRT, Non-Real-Time）
- 多域交互
- 嵌入式系统、固件（Firmware）、用户界面（UI/UX）、临床工作流
每个模块可能跨多个领域（Embedded、Firmware、Real-Time / Non-Real-Time、Clinical Workflow），并且互相依赖。
3.1 系统自由度与控制复杂度
设系统自由度为 ，则机器人运动控制可能涉及 联合空间的状态向量：
控制系统需要计算每个自由度的控制指令 ，并保证手术操作的 实时性（Real-Time）：
其中 为力反馈传感数据。
3.2 软件规模
- 软件规模：
- 模块依赖复杂，每个模块可能与 5-10 个其他模块交互
- 实时与非实时任务混合（RT/NRT），需要严格的调度和同步策略
3.3 风险与验证
- Class-C 软件：任何软件故障可能导致严重伤害
- 验证与验证（V&V）要求：
- 单元测试（Unit Testing）
- 集成测试（Integration Testing）
- 系统测试（System Testing）
- 仿真和训练验证（Simulation / Training）
- 回归测试与安全验证（Regression & Safety Testing）
- 多域集成：嵌入式、固件、用户界面、临床工作流需要协同工作
- 实时性保证：关键控制任务必须满足硬实时要求
- 安全与可靠性：必须满足医疗安全标准（IEC 62304）
- 复杂依赖管理：模块间依赖关系复杂，需要 SBOM / CBOM 记录
- 验证复杂性：百万行代码 + 多域系统使验证、回归测试和功能安全极具挑战
设系统软件模块集合为 ，每个模块的残余风险为 ，系统总残余风险为：
目标是：
同时，实时控制模块需要满足时间约束：
其中 为实时任务集合， 为执行时间。
- 本案例为 Class-C 医疗器械，任何软件故障可能导致严重伤害。
- 系统高度分布式，包含超过 60 自由度的机器人控制、多域嵌入式模块、用户界面和云端功能。
- 软件规模大（数百万行 C++），依赖复杂模块和第三方组件。
- 风险管理和验证必须严格执行 IEC 62304 要求，确保功能安全和实时性。
在复杂医疗机器人系统（如 Class-C 医疗器械）中，选择 C++ 作为主要开发语言有多方面原因。这个问题简单却常被忽略。
- C++ 符合多种工业和嵌入式标准。
- 在医疗设备、汽车或航空等行业中，C++ 能满足 IEC 62304 等安全标准的要求。
- 数学化表示：假设软件标准集合为 ，则选择 C++ 可满足：
- C++ 能与多种库和系统互操作，包括嵌入式 RTOS、操作系统（OS）及中间件。
- 支持跨平台开发和硬件接口。
- 对机器人控制系统中高频控制循环尤为重要：
C++ 能实现高性能实时任务。
- C++ 已存在 30+ 年，语言成熟、稳定。
- 拥有大量文档、案例和社区支持。
- 高效的 执行速度 和 内存控制能力，适合嵌入式和实时控制。
- 能直接操作硬件资源，减少延迟。
数学化表示实时任务执行时间 ：
常用库：
利用这些库，可以快速实现复杂功能，同时保证性能和可维护性。
- C++ 可在不同 OS 和架构（Architecture）上运行，例如 RTOS、嵌入式 Linux、Windows 等。
- 在高频控制循环（High frequency control loop）中可保持实时性：
选择 C++ 的主要原因：
- 标准兼容：满足 IEC 62304 等医疗标准。
- 高性能：适合高频控制和实时任务。
- 丰富库和框架：加速开发，支持复杂算法（AI、视觉、机器人控制）。
- 可互操作性：跨平台和跨系统集成能力强。
- 成熟与社区活跃：开发经验丰富、资源充足。
- 可移植性：可在 RTOS、嵌入式、桌面等多平台运行。
在 Class-C 医疗设备中，C++ 的使用虽然性能强大，但也存在安全性与功能安全风险。我们需要通过 架构设计和风险驱动方法来缓解这些风险。
核心思想
- 软件架构设计应以 风险缓解为核心目标。
- 将软件系统划分为多个 软件项（SW Item），每个软件项根据其风险等级进行分类（Class A/B/C）。
软件项示例
高风险模块（Class C）必须严格控制和验证，低风险模块（Class A）可适度放宽。
数学化表示：
设系统软件模块集合为 ，每个模块的风险等级为 ，系统风险为：目标是：
在实际运行中，软件可能遇到多种不利条件：
- 故障（Faults）
- 包括软件缺陷、硬件异常、通信错误。
- 资源有限（Limited Resources）
- 内存、CPU、存储、带宽限制。
- 性能有限（Limited Performance）
- 系统需要满足实时控制或响应需求。
架构策略
- 物理/逻辑隔离（Physical/Logical Segregation）
- 高风险模块隔离，避免故障传播。
- 降低耦合，提高内聚（Reduce Coupling & Enhance Cohesion）
- 模块独立性高，便于测试和验证。
在医疗机器人系统中，软件模块可分为不同 实时等级：
3.1 非实时（Non-Real Time, NRT）
- 特征：没有严格的时间截止要求。
- 示例：日志记录（Logging）
- 数学化：时间截止 非严格：
3.2 软实时（Soft Real Time, Soft RT）
- 特征：偶尔少量未满足截止时间是允许的，但会影响性能。
- 示例：视觉叠加（Vision Overlays）、UDP 通信
- 数学化：
3.3 硬实时（Hard Real Time, Hard RT）
- 特征：截止时间严格不可违背。
- 示例：控制系统（Control Systems）、实时视觉（Vision）
- 数学化：
- 任务通常运行在 Bare-Metal 或嵌入式 RTOS 上。
- 风险驱动架构
- 按模块划分风险等级（Class A/B/C），对高风险模块严格控制。
- 模块隔离与耦合优化
- 降低耦合，提高内聚，减少故障传播。
- 实时性分级
- NRT/Soft RT/Hard RT 区分，实现不同时间约束管理。
- 资源和性能管理
- 预防资源耗尽和性能瓶颈，保证系统安全性。
通过上述方法，即便使用复杂的 C++ 软件，也能在 Class-C 医疗机器人系统中 安全可靠地运行。
在 Class-C 医疗器械软件开发中，规范化编码和编译器强化（Compiler Hardening） 是确保安全与可靠性的重要环节。
编码标准是 软件验收标准（Software Acceptance Criteria） 的关键部分，IEC 62304 附录 B.5.5 明确指出：
对医疗软件来说，符合编码标准是软件验证的一部分。
常用编码标准示例
数学化表示
设软件源代码文件集合为 ，每个文件 的合规性函数为 ：
整个软件的编码标准合规性：
目标：
FDA 建议
- 将 编译器警告视为错误（Warnings as Errors）
- 使用严格的编译选项：
示例选项：
-Werror -Wall -Wextra
-Wformat -Wformat=2 -Wconversion -Wimplicit-fallthrough
-Werror=format-security
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3
-D_GLIBCXX_ASSERTIONS
-fstrict-flex-arrays=3
-fstack-clash-protection -fstack-protector-strong
-Wl,-z,nodlopen -Wl,-z,noexecstack
-Wl,-z,relro -Wl,-z,now
-Wl,--as-needed -Wl,--no-copy-dt-needed-entries
作用
- 警告强化
- 将潜在问题提前发现为编译错误，防止忽略。
- 缓冲区保护
_FORTIFY_SOURCE、-fstack-protector-strong提供栈保护，减少缓冲区溢出风险。
- 格式安全
-Wformat=2和-Werror=format-security防止格式化字符串漏洞。
- 内存/执行保护
-Wl,-z,noexecstack,-Wl,-z,relro,-Wl,-z,now防止栈/堆代码注入攻击。
数学化表示：设软件漏洞概率为 ，编译器强化后降低概率为 ，则残余漏洞概率：
理想情况下，，将漏洞概率降至极低。
- 编码标准保证软件设计和实现一致性，减少逻辑错误和安全漏洞。
- 编译器强化通过严格编译选项、防护措施和警告转错误，提前发现潜在问题，提高安全性。
- 数学化模型可量化编码标准合规性和编译器强化对漏洞概率的降低效果：
结合编码标准与编译器强化，是 Class-C 医疗软件安全开发的核心实践之一。
目标：提高 内存安全、类型安全、线程安全，降低医疗 Class-C 软件的潜在漏洞概率。
这一页主要列出了常用的重要编译器选项、其支持的版本，以及它们对安全性的作用。
编译器扩展（GCC 扩展等）可能导致不可移植或未定义行为，因此 医疗软件应禁止使用。
下表为并逐项说明其作用：
转换/隐式转换警告
ightarrow y in mathbb{U} ext{ 可能导致 } y
eq x
栈保护（Stack Protection）
保留空指针检查
if (p == nullptr) { /* handle */ }
禁止假设整数不溢出
禁止 strict-aliasing 优化
自动变量初始化
int x; // 可能是垃圾值
数学意义：
栈冲突保护
Sanitizers 在调试阶段使用，不建议在最终生产构建中开启，但在医疗软件开发中是 必需的验证步骤。
eg ext{sync}(w_1,w_2)
- 整数溢出
- 空指针解引用
- 越界访问
- 错误的别名访问
等。
UB 数学定义：
编译器强化的 3 大核心方向：
- 栈保护
- 初始化未定义变量
- 去除危险优化
- 所有隐式/指针转换 → 视为错误
- 禁止不兼容类型的赋值
- 使用 TSan 捕获数据竞争
- 使用 RealtimeSanitizer 捕获实时约束违反
目标是将潜在漏洞概率：这对于 Class-C 医疗系统至关重要。
医疗器械软件（如 IEC 62304 要求）通常限制自动持续部署（CD），因为每一个版本都需要验证、确认、文档、风险评估。因此这里强调：
在医疗器械行业，强烈偏好以下方式来降低风险：
（1）Pre-merge Checks（合并前检查）
在代码合并到主分支之前执行的自动检查，包括：
- 编译
- 单元测试
- 静态分析
- 代码格式
- 安全检查
（2）Pre-commit Hooks（提交前钩子）
开发者本地提交代码之前自动运行：
- clang-format
- clang-tidy
- 轻量级单元测试
- 静态分析
可避免大量错误进入仓库。
（3）Local Dev（本地开发自检）
在医疗软件中，希望尽可能多的问题在开发者本地被发现，而不是等到 CI 的服务器上。
AI 工具用来：
- 代码生成
- 解释警告
- 进行代码自动修复
- 文档自动生成
但法规要求 AI 工具必须： - 可验证
- 结果可审计
- 不能直接用于安全关键逻辑的自动生成
下面解释图中的内容：
包括：
IDE 内置的静态分析：
如 Clang-Tidy, Visual Studio Analyzer。
深度静态分析工具：
如：
- SonarQube（代码质量/安全热点）
- Coverity
- CodeQL
这些工具在医疗软件开发周期中用于： - 发现潜在漏洞
- 查找未定义行为
- 自动识别“安全热点”
- 控制技术债务
┌────────────────────────────────────────────────┐
│ Local Dev 本地开发 │
│ 开发者在本地编写代码，运行编译、单测、格式化 │
└────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ Pre-Commit Hooks 提交前钩子 │
│ 自动运行 clang-format、clang-tidy、基本单测 │
│ 在提交前尽早发现问题 │
└────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ Multi-platform Build 多平台构建 │
│ Linux / Windows / macOS / Embedded / ARM 等 │
└────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ Multi-compiler Build 多编译器构建 │
│ GCC / Clang / MSVC / ARM GCC / Cross 等 │
└────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ Test Build 测试构建 │
│ 开启各种 Sanitizers 的测试构建： │
│ • ASan（内存越界） │
│ • TSan（数据竞争） │
│ • LSan（内存泄漏） │
│ • UBSan（未定义行为） │
│ • MSan（未初始化内存） │
│ • RTSan（通用运行时检测） │
└────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ Quality Gate 质量门禁 │
│ 使用 SonarQube / Coverity / CodeQL 等 │
│ 不允许新 Bug │
│ 不允许新安全漏洞 │
│ 安全热点需要人工审核 │
│ 新代码覆盖率达标 │
│ 限制技术负债与重复代码 │
└────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ Code Review 代码审核 │
│ 人工审查逻辑、接口、风险、可维护性 │
└────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────┐
│ Merge 合并 │
│ 审核通过 + 所有检查通过 → 代码进入主分支 │
└────────────────────────────────────────────────┘
CI 流程从本地开发开始，确保问题尽可能早被发现：
- 本地开发：开发者本地编译和测试。
- Pre-commit Hooks：自动格式化、静态分析。
- 多平台构建：保证多个系统/架构一致性。
- 多编译器构建：确保在不同编译器下无问题。
- Sanitizer 测试构建：运行时内存、并发、未定义行为检测。
- Quality Gate：SonarQube / Coverity 严格检查质量。
- 代码评审：人工把关安全、架构、逻辑。
- 合并：通过全部检查后进入主分支。
这个流程特别适合：
医疗器械（IEC 62304）
汽车（ISO 26262）
航空（DO-178C）
任何对安全/质量要求极高的 C++ 项目
多平台、多编译器
要构建并测试：
- GCC
- Clang
- MSVC
- ARM GCC
- Embedded Cross Compiler
确保软件在多种目标平台上一致可靠。
CI 中的 Quality Gate（如 SonarQube）必须确保：
1. No new bugs are introduced
新的代码不能新增可检测的 bug。
2. No new vulnerabilities are introduced
不能产生新的安全漏洞。
3. All new security hotspots are reviewed
安全敏感区域必须人工审查，例如：
- 内存管理
- 系统调用
- 网络通信
- 加密
4. New code has limited technical debt
新代码不能引入过多技术债务，否则长期累积会变成风险。
5. New code has limited duplication
重复代码越多，质量越差，维护成本越高。
6. New code is properly covered by tests
新功能必须有：
- 单元测试
- 集成测试
- 功能验证
在医疗软件中这是法规要求。
CI/CT/CD 在安全关键系统（如医疗设备）中必须以风险为驱动力。
流程强调：
- 尽可能在本地和合并前发现问题
- 广泛使用静态分析和 Sanitizers
- 所有新代码经过质量门禁（Quality Gate）
- 必须人工代码审查，不能完全依赖自动化验证
- 限制持续部署，因为每个版本都需严格验证与文档
“持续测试”强调在软件生命周期的**越靠前越好（Shift Left）**的位置进行测试，而不是等到开发后期才做。
在安全关键系统（Medical / Automotive / Avionics）中，这非常重要，因为早期发现缺陷可以：
- 降低风险
- 减少修复成本
- 提高系统可靠性和可预测性
核心思想：
越早测试，越频繁测试，用更多类型的测试覆盖更多潜在问题。
传统软件开发常常在开发完成后才做大量测试；但在医疗和机器人系统中，这样做风险太高。
“Shift Left”意味着：
- 在编码阶段就启动测试
- 在本地构建中使用 Sanitizers、Fuzzing、单测
- 在CI 早期就做静态分析
- 在系统集成前通过仿真、模型、故障注入捕获错误
核心目标：
尽一切可能把运行时问题、内存问题、并发问题，提前到开发左侧就发现，而不是上线后。
Continuous Testing 涵盖非常广的测试策略：
Sanitizers 是编译器提供的运行时检测工具，用于捕获危险漏洞：
- AddressSanitizer（ASan）：检测内存越界、use-after-free
- ThreadSanitizer（TSan）：检测数据竞争
- LeakSanitizer（LSan）：检测内存泄漏
- UndefinedBehaviorSanitizer（UBSan）：检测未定义行为
- MemorySanitizer（MSan）：检测未初始化内存
- RealtimeSanitizer（RTSan）：检测实时性违规（新兴）
这些测试能捕获 C++ 中最危险的缺陷，是医疗/航空系统的黄金标准。
在真实硬件不可用或代价过高时，用仿真环境进行测试：
- 机器人运动、机械臂轨迹
- 医疗设备操作流程
- 网络与通信仿真
- 故障场景、罕见事件模拟
仿真允许： - 大规模重复实验
- 验证边界情况
- 在无风险环境中测试可能导致伤害的场景
真实硬件上的测试，即：
- 传感器与执行器
- 控制器、嵌入式板卡
- 机器人关节与驱动
- 医疗设备真实交互
用于捕获仿真无法模拟的： - 时序偏差
- 噪声
- 机械摩擦
- 电磁干扰（EMI）
- 串口/USB/网络真实延迟
让系统在极端条件下运行：
- 最大负载
- 高频调用
- CPU 饱和
- 带宽受限
- 极端临床操作场景
- 长时间运行（数小时/数天）
目标：
在极端条件下系统仍然能稳定、安全地运行。
由专门的 SQA 团队执行：
- 流程一致性
- 风险缓解验证
- 文档一致性
- 安全标准符合性（IEC 62304 等）
自动生成随机或半智能输入，以发现异常情况：
- 通信协议 Fuzzing
- API Fuzzing
- 消息/序列/事件顺序扰动
- 机器人指令、控制数据 Fuzzing
用于发现： - 崩溃
- 死锁
- 异常逻辑流
- 安全漏洞（特别有效）
观察系统长期运行的稳定性：
- 持续工作数小时、数天
- 检测内存泄漏、资源泄漏
- 文件句柄、线程、socket 泄漏
- 随机硬件故障恢复能力
检查：
- 延迟（latency）
- 吞吐量（throughput）
- 控制回路周期（控制周期抖动）
- 实时系统 deadline 保证
特别在机器人系统中很关键。
主动引入故障来观察系统是否安全：
- 传感器故障
- 通信丢包
- 电源中断
- 数据损坏
- 软件异常（抛异常、null pointer）
- 越界事件
目标：
验证系统“Fail-safe / Fail-operational”的能力。
验证新代码不会破坏旧功能：
- CI 自动化
- 覆盖率监控
- 回放历史测试用例
- 大规模系统行为对比
回归测试是医疗类 C++ 软件的绝对必要部分。
Continuous Testing 还强调测试的分层：
- 测试单个模块/类
- 逻辑隔离
- 覆盖各种路径与边界条件
- 用 GTest/GMock 等框架
- 医疗器械要求：覆盖率通常 ≥ 80%
- 模块/组件之间的交互
- 通信协议、API、数据流
- 控制链路（sensor → algorithm → actuator）
机器人、医疗系统特别依赖此层。
从用户操作 → 系统 → 输出完整流程：
- 外科医生操作界面 → 机械臂 → 图像系统 → 数据记录
- 操作台输入 → 控制器 → 执行单元
- 整个设备生命周期的真实场景模拟
用于证明：
医疗器械在真实临床使用条件下是安全的。
在医疗器械、机器人系统等安全关键软件中，能够做到频繁、安全、可靠地进行软件升级是一种极高价值的能力。
它带来的优势包括：
- 更快修复缺陷
- 更快应对安全威胁
- 更快获得性能提升
- 更快更新第三方库（SOUP）
- 更容易保持系统长期安全可维护
换句话说：
团队越能频繁且安全地升级系统，整个产品就越难被安全漏洞击倒，也越容易长期保持高质量。
医疗系统常常依赖外部模块（SOUP），例如：
- 第三方 C++ 库（Boost、Qt、Eigen、OpenCV …）
- 操作系统（Linux/RTOS）
- 中间件（ROS、DDS、Protobuf、ZeroMQ …）
- 编译器（GCC / Clang / MSVC）
- C++ 语言版本（C++11 → 17 → 20 → 23）
这些模块不断被发现新漏洞，也不断被更新和修复。
频繁升级 SOUP 可以： - 获得最新安全补丁
- 避免已知漏洞被攻击者利用
- 改善系统稳定性和性能
- 获得更安全的新 C++ 语言特性（如 C++20/23 的强类型 + 安全 API）
- 获取供应商的安全认证或合规支持
对于医疗系统来说非常关键。
频繁升级带来多重收益：
** 新功能（New features）**
库和 OS 升级经常增加新能力，比如更快的数学库、更好的图像处理、更安全的加密模块。
** 更强的安全性（Security++）**
第三方持续修补漏洞（如 OpenSSL、libc、Boost）。
升级让你始终在使用最安全的版本。
** Bug 修复（Bug fixes）**
你不想自己修复别人修过的 bug；升级即可自动获益。
** 稳定性与优化（Stability & Optimizations）**
编译器升级可能自动让程序运行得更快、占用更少内存。
** 更安全的 C++ 版本**
每一版 C++ 都提升安全性，例如：
- C++17 的
std::optional减少 nullptr - C++20 的 concept 提升模板安全
- C++23 加入更多强类型与 safer API
** 更好的工具链（Enhanced tooling）**
例如：
- 更快的静态分析器
- 更精确的 sanitizers
- 更智能的 IDE
- 更健壮的调试器
** 合规性提升（Compliance）**
某些第三方供应商会提供：
- 安全认证
- 符合 IEC 62304 / ISO 14971 的模块
- 合规文档
- SBOM / CBOM 追踪支持
频繁升级不是“想做就能做”的，需要工程文化与技术基础结构支撑。
** 模块化与解耦架构（Modular & Decoupled Architecture）**
减少依赖耦合 → 升级风险更小
例如使用：
- 清晰的 API
- 独立构建的组件
- 基于接口的依赖倒置
升级某个组件时不需要改动整个系统。
** 定期技术债审查（Tech Debt Reviews）**
不要积累依赖老版本库、过时接口、不受支持版本。
越晚清理，升级成本越高。
** 安全与合规追踪（Security / Compliance Tracking）**
通过 SBOM / CBOM 追踪依赖库的版本与漏洞状态。
例如：
- 自动扫描 CVE
- 定期更新库版本
- 维护内部软件供应链文档
** 成熟的升级测试框架（Testing Framework for Upgrades）**
没有足够的自动化测试，就不可能频繁升级。
必须具备：
- 单元测试
- 集成测试
- E2E 流程测试
- 仿真测试
- Fuzzing
- Sanitizers（ASan/TSan/UBSan/LSan）
- 性能与压力测试
否则升级一次就会引发不可控的风险。
** 良好的依赖管理（Dependency Management）**
使用：
- Conan（强烈推荐）
- Vcpkg
- CMake FetchContent（有限推荐）
确保： - 依赖版本管理可控
- 构建可重现
- 版本升级有记录
- 跨平台一致性强
** 完整的文档（Documentation）**
包括：
- 依赖说明
- 架构文档
- 安全报告
- 版本迁移指南
这样新版本迁移不会成为黑箱操作。
频繁、安全地升级系统（尤其是 SOUP）是医疗类 C++ 系统保持长期安全、性能领先和合规性的核心能力。
它需要：
- 正确的架构
- 完整的测试体系
- 自动化的 CI/CD
- 强依赖管理
- 严格的安全追踪
- 健康的工程文化
医疗机器人系统是一个高度复杂、分布式、多领域的软件系统。
为了在安全性、实时性与性能之间取得平衡，通常必须将整个软件划分为不同的领域（Domain），并根据领域的风险等级（IEC 62304 Class A/B/C）和实时性要求应用不同的设计策略。
医疗设备按照功能风险等级可分为不同的软件项（Software Item）：
- Class C：最高风险（可能导致严重伤害或死亡）
- Class B：中风险
- Class A：低风险
文中给出的示例结构：
SW System / Item
(Class C)
├── SW Item X (Class C)
├── SW Item W (Class A)
├── SW Item Y (Class B)
└── SW Item Z (Class C)
这说明：
- 整个系统可能是 Class C
- 系统内部有多个子系统，不同子系统有不同的风险等级
- 每个子系统应使用不同的工程方法、语言特性与流程约束
医疗机器人包含许多任务，但这些任务的实时性需求差异巨大。
因此需要按实时性来划分软件领域，避免高风险任务被非关键任务干扰。
下面是文中描述的四种实时性领域。
特征：
- 没有严格的时间限制
- 延迟不会造成安全风险
示例：
- Logging（日志系统）
- 数据上传
- 文件 IO
- 云同步、调试分析
系统环境：
- NRTPC（Non-Real-Time PC）
- Linux / Windows 都可以
特征：
- 有时间要求，但偶尔延迟可以接受
- 性能不足会影响体验，但不会造成危害
示例：
- Vision overlays（例如视觉界面叠加）
- UI 刷新
- 部分图像处理
系统环境：
- NRTPC 或 RTOS（可选）
特征：
- 时间限制严格
- 偶尔延迟会导致功能中断或系统故障
示例：
- UDP 通信（同步控制数据）
- 实时传感器数据处理
系统要求：
- 通常运行在 RTOS（实时操作系统）
- 必须满足硬性时间约束，但比 Hard RT 稍弱
特征：
- 时间约束严格到毫秒级或微秒级
- 一旦错过最后期限就可能造成严重后果
- 是医疗机器人控制系统的核心
示例：
- 控制系统主环（Control Loops）
- 实时视觉（某些导航模块）
- 力反馈（Haptics）
- 紧急停止逻辑（E-stop）
系统环境：
- Bare Metal
- Embedded
- RTOS
- 完全排除非确定性因素
在医疗机器人进入患者体内后，某些路径属于 Safety-Critical Path（安全关键路径）。
在这些区域中，C++ 的使用必须受限，避免任何可能导致未定义行为或非确定性的语言特性。
可能导致未定义行为（Undefined Behavior, UB）：
- 指针算术（pointer arithmetic）
- 访问未初始化变量
- 越界读写（out-of-bound access）
- 错误的类型转换（improper casts, reinterpret_cast 滥用）
- 空指针解引用（nullptr dereference）
- 缓冲区破坏（buffer overflow）
- 数据竞争（race conditions）
上述任何行为在医疗 Class C 系统中都是不可接受的。
在医疗机器人控制循环中，我们必须保持每个周期时间确定、行为确定。
因此应避免：
① 动态内存分配（new / malloc / vector::push_back）
- 易造成内存碎片化
- 分配时间不可预测
- 分配失败可能导致控制系统崩溃
→ 控制环必须使用 静态内存 或 预分配池（Memory Pool）。
② 异常处理（C++ Exceptions）
异常会造成：
- 栈解 unwinding 不可预测
- 延迟不可预测
- 无法精确界定执行路径
因此在 Class C 代码中通常 关闭异常机制（-fno-exceptions）。
包括：
- Mutex 锁竞争（unnecessary locking）
- Blocking I/O（网络、磁盘、串口）
- Sleep / Wait
- 日志写入
- 文件系统操作
阻塞调用会破坏控制环的实时性。
在 Hard RT 中必须使用： - 无锁结构（Lock-free）
- Wait-free 数据结构
- Ring Buffers
- 非阻塞算法
- 不阻塞的 IO（如 UDP + 非阻塞接口）
医疗机器人领域需要根据风险等级和实时性，将系统划分成不同 Domain，并对 C++ 的使用施加不同的限制。越靠近 Safety-Critical Path，越需要消除不确定性。
核心原则：
- 高风险域（Class C + Hard RT）
→ 不允许动态内存
→ 不允许异常
→ 不允许阻塞操作
→ 不允许 UB 相关的 C++ 特性
→ 要求完全可预测的执行时间 - 中风险域（Class B + Firm RT）
→ 可接受轻微不确定性
→ 有限操作系统调用 - 低风险域（Class A + NRT）
→ 可使用完整 C++ 功能集
→ 允许动态内存、异常、I/O
在实时系统、嵌入式系统或高性能系统中，动态内存分配是昂贵且不可预测的，原因包括：
- 分配/释放开销大：
malloc/new会触发系统调用或锁。 - 碎片化（fragmentation）：导致长期运行后可用内存减少。
- 不可预测性：分配成功/失败时间不确定。
- 异常开销：C++ 的
new在失败时会抛出std::bad_alloc。
这使得 DMA 在 软实时/硬实时 代码中常常被禁止。
C++ 标准库中许多常用类型都包含动态内存：
常见 会进行 DMA 的类型：
std::vectorstd::mapstd::setstd::stringstd::unique_ptr（管理堆对象时）std::shared_ptrstd::functionstd::any
这些容器背后都依赖 Allocator 模型：
template<class T, class Allocator = std::allocator<T>>
class vector;
所以一旦 vector 需要扩容，就会触发类似：
因此 任何 push_back / emplace / resize 都可能触发 DMA。
void Log(const std::string& msg) { /* ... */ }
int main() {
Log("some static string constant");
}
虽然 "some static string constant" 是一个 string literal，但它会隐式转换为 std::string：
std::string temp("some static string constant");
而 std::string 的构造 可能进行 DMA（取决于 SSO，大字符串必定 DMA）。
因此 DMA 可能发生在看似“安全”的代码中。
人很难凭记忆区分哪些操作会触发动态内存分配。
所以要通过 工具 来保证：
- 静态断言（static assert）
- 静态分析（clang-tidy, cppcheck）
- 动态分析（valgrind, ASan）
- 单元测试监控是否发生了内存分配
下面重点讲 “通过单元测试监控 DMA”。
这是你贴的代码片段的核心含义：
目标
在单元测试中：
你可以在测试环境中提供重载：
void* operator new(std::size_t s) {
HeapMonitor::SetHeapDetected();
return malloc(s);
}
void* operator new[](std::size_t s) {
HeapMonitor::SetHeapDetected();
return malloc(s);
}
void operator delete(void* p) { free(p); }
void operator delete[](void* p) { free(p); }
这样：
- 任何
new/new[]发生时就调用HeapMonitor::SetHeapDetected() - 把标志设为
true
数学上可以描述为：
class HeapMonitor {
public:
HeapMonitor() = default;
static void SetHeapDetected() {
is_heap_allocated_ = true;
}
bool IsHeapAllocatedAndReset() {
bool heap_allocated = is_heap_allocated_;
is_heap_allocated_ = false;
return heap_allocated;
}
private:
static bool is_heap_allocated_;
};
// 静态变量定义
bool HeapMonitor::is_heap_allocated_ = false;
描述：
is_heap_allocated_：一个 全局的布尔 flag- 如果发生 DMA，这个 flag 会被设为
true IsHeapAllocatedAndReset()会：- 返回这个 flag
- 清零它
常用于单元测试：
TEST(CriticalTest, NoHeapAlloc)
即：
若 CriticalFunction() 进行了动态内存分配，测试就会失败。
PPT 里提到：
可能重载 malloc/free，但不容易
使用 LD_PRELOAD 加载一个库来替换 malloc
在 Linux 中你可以写一个.so：
里面 override：
void* malloc(size_t size) {
HeapMonitor::SetHeapDetected();
return __libc_malloc(size);
}
然后执行：
LD_PRELOAD=./my_malloc_monitor.so ./your_program
所有 malloc 都会被你拦截。
你贴的内容主要说明：
为什么 DMA 在关键路径中必须被禁止
- 不确定
- 耗时
- 可能抛异常
- 可能碎片化
如何识别 DMA
- 标准库容器、智能指针、function/any 可能触发
- 隐式构造 string 也可能触发
如何检测 DMA
- 重载
new/malloc - 通过 HeapMonitor 记录是否发生
- 单元测试中验证
如何系统防止 DMA
- 静态断言、分析工具、测试拦截
——详细理解
在性能关键区（critical path）或实时系统（real-time system）中，要尽量避免运行过程中的动态内存分配（DMA），因为动态分配不确定、可能失败、可能阻塞，还可能造成抖动（jitter）。
因此，常见策略是：
把所有动态内存申请都提前到“初始化阶段”，而不是在系统循环中分配。
// Move all allocation to initialization
std::vector<std::unique_ptr<Sensor>> sensors = BuildSensors(configuration);
while (keep_going) {
for (auto& sensor : sensors) {
Use(*sensor);
}
}
下面逐行解释。
std::vector<std::unique_ptr<Sensor>> sensors = BuildSensors(configuration);
含义：
BuildSensors(configuration)会根据配置生成所有需要的Sensor对象。- 每个
Sensor由std::unique_ptr<Sensor>管理，因此对象位于 堆（heap）。 - 但重要的是：
所有new（动态内存分配）都在程序开始时完成。
数学上可理解为：即：
初始化阶段可能进行内存分配；
运行阶段严格禁止任何动态内存分配。
while (keep_going) {
for (auto& sensor : sensors) {
Use(*sensor);
}
}
解释：
- 这里是系统的主循环，例如实时线程、控制循环、传感器读写循环等。
- 循环中只使用已经分配好的对象。
- 不会再创建新的对象，因此：
意思是：
在整个运行阶段的时间区间内，动态内存分配次数应为 0。
原因：
- 动态内存分配开销不可预测
可能耗时 、 或更久，影响实时性能。 - 可能失败（std::bad_alloc）
在实时循环中无法接受异常抛出。 - 可能造成碎片化
导致后面需要分配时失败。 - 可以提前规划内存使用量
如果所有内存都在初始化阶段分配，则整个运行期间：这种确定性对于医疗设备、航空设备、控制系统至关重要。
你贴的代码表达的是一个核心思想：
不要在主循环中进行动态内存分配，把所有的分配都提前放到初始化阶段。
这样可以保证系统在关键路径中：
- 没有 malloc/new
- 没有 realloc
- 没有隐式分配（如 std::string 扩容、vector 派生初始化）
从而提升系统的 确定性（determinism） 和 可预测性（predictability）。
要在实时系统、控制循环、医疗器械软件等关键路径中避免 DMA（Dynamic Memory Allocation），就要 避免使用默认会进行动态分配的标准容器和字符串。
标准库中的容器默认使用：
std::allocator<T>
它会在需要时调用 operator new 进行堆分配。
std::vector<T, Allocator = std::allocator<T>>
std::map<Key, T, Compare, Allocator>
std::set<Key, Compare, Allocator>
std::basic_string<CharT, Traits, Allocator>
解释：
- 这些容器都使用模板中的
Allocator参数。 - 若使用默认
std::allocator，则会进行 heap 分配（动态内存分配）。 - 在运行期间执行 push、insert、append、resize 等操作时都会触发 DMA。
数学上可以理解为：
对于一个容器 ，若其 allocator 为 ：例如：
扩容时必定调用：
关键思路：
提供一个特殊的 Allocator，使容器在初始化阶段提前预分配好内存，并在运行时不再分配。
也就是说：方法包括：
- 预分配 capacity（如
vector.reserve(N)） - 使用自定义 Allocator
- 使用专门的“无动态内存”容器实现
这些叫 Allocator Strategy（分配策略）。
很多大型系统已经提供了 “避免 DMA 的容器”：
static_vector<N> 保证：你列出的：
bitset
array
tuple
的确是 STL 里少数 完全不使用动态内存 的容器/对象：
1. std::bitset<N>
- 位图容器
- 大小 是编译期常量
- 完全栈上，不分配 heap
2. std::array<T, N>
- 固定长度数组容器（栈上）
- 数量 是编译期常量
- 没有 DMA
数学描述：
3. std::tuple
- 内部用组合（composition），所有成员对象直接存储在 tuple 内
- 不会动态分配内存
（除非成员对象自己动态分配）
你贴的内容主要讲：
如何避免在实时/关键路径中发生动态内存分配：
- STL 容器默认会 DMA，因为使用
std::allocator - 解决方法是：
- 使用预分配（reserve/capacity）
- 使用自定义 Allocator
- 使用替代容器（boost、chromium）
- 使用原生不分配 heap 的 STL 容器（array, bitset）
最终目标：使系统达到确定性（deterministic） 和 可预测性（predictable）。
这段内容展示了：
- 一种含有动态内存分配的写法（不推荐）
- 一种 generic 但不分配 heap 的写法（推荐）
- 一种最简单、最具体、无 heap 的写法（非常推荐）
核心思想：
关键路径中禁止动态内存分配（DMA），所有对象尽量放在栈上。
数学上可表示：
int main() )) {
std::cerr << "Error
";
return 1;
}
for (auto &worker : workers)
}
}
问题 1：std::vector 本身可能动态扩容
vector.push_back() 可能调用：
从而 —— DMA 发生。
问题 2：unique_ptr<MyInterface> 包含多态对象
new SensorReader
new GravityStabilizer
都是堆分配，触发 DMA。
问题 3：new (std::nothrow) 只是避免抛异常
它不会避免动态分配，只是：
仍然有 DMA 行为。
数学表示：
因此 不适合实时关键路径。
int main() {
std::array<std::variant<SensorReader, GravityStabilizer>, 2> workers{
SensorReader(),
GravityStabilizer()
};
for (auto &worker : workers) {
std::visit([](auto &w) { w.DoWork(); }, worker);
}
}
优点 1：std::array 不会 DMA
容量在编译期固定：
优点 2：std::variant 内联存储
variant 的所有备选类型都放在同一个固定内存块里，不会 new。
优点 3：对象放在栈（stack）中
SensorReader 和 GravityStabilizer 直接是本地对象，内存布局确定、无 heap。
缺点：类型比较 “generic”
访问使用：
std::visit
较复杂，但仍是 无 DMA 的泛型结构。
整个运行期间不发生动态内存。
int main() {
SensorReader sensor;
GravityStabilizer stabilizer;
sensor.Read();
stabilizer.Apply();
}
- 所有对象都在栈上，生命周期清晰
- 没有 vector
- 没有 pointer
- 没有 variant
- 没有 new
- 无任何间接访问、泛型、虚函数开销
这是 最确定性（deterministic） 的写法。
数学表达：即：整个程序无动态内存。
这段内容的核心思想：
在关键路径中，不要使用会导致动态内存分配的容器，也不要用 new。
三个示例表示逐渐优化过程：
- vector + unique_ptr → 有 DMA → 不合适
- array + variant → 无 DMA → 通用性强
- 具体类型栈对象 → 无 DMA → 性能最好
最终目标：
在 C++ 中，异常机制（Exception）是一种错误处理方式，通过 throw / try-catch 抛出和捕获异常。
但在实时系统、嵌入式系统、医疗软件等关键路径中：
- 异常可能导致不可预测的控制流
- 异常处理开销不可确定
- 堆栈展开（stack unwinding）可能触发 DMA
因此，很多项目选择替代异常的错误处理方案。
替代方案主要可以分为 三大类：
- Optional / 可选类型
- Error Code / 错误码
- Result Type / 返回值类型封装
std::optionalboost::optionalabsl::Optionalstd::optional<int> maybeValue = GetValue();
if (maybeValue.has_value()) {
int v = maybeValue.value();
} else {
// 处理不存在的情况
}
特点：
- 无 DMA（通常放在栈上）
- 无异常抛出
- 适合可选返回值
std::system_errorstd::error_code 使用- 高性能
- 无异常开销
- 可在实时/嵌入式中使用
缺点： - 调用者必须检查返回值，容易忽略
- 可读性较差
std::expectedtl::expectedstd::expectedBoost.Outcomeabsl::Statustl::expected<int, std::string> Compute()
auto res = Compute();
if (res) { /* 使用 res.value() */ }
else { /* 处理 res.error() */ }
特点：
- 类型安全，必须显式处理错误
- 可避免异常机制开销
- 更易于组合（函数链式调用）
- 异常机制虽然方便，但在关键路径中可能不可预测且有堆栈开销
- 替代方案：
- Optional 类型 → 表示值可能存在或不存在
std::optional/boost::optional/absl::Optional
- 错误码 → 函数返回错误码或状态
std::system_error/ 自定义 enum
- 结果类型封装 → 封装成功或错误
std::expected/tl::expected/Boost.Outcome/absl::Status
数学上，这些方案都是值的二分或多态封装：
在医疗器械、嵌入式或实时系统中，推荐使用 Optional / Result Type / Error Code 替代异常，以提高确定性（determinism）和可预测性（predictability）。
在实时系统、嵌入式系统和关键路径软件中，阻塞调用会导致不可预测延迟，因此必须谨慎识别和避免。
阻塞调用指：
调用发生时，线程会 等待某些条件完成，期间无法继续执行其他任务。
常见阻塞调用类型：
- 文件 I/O（File IO）
例如read()/write()等可能等待磁盘操作完成 - 网络 I/O（Network IO）
例如recv()/send()，等待网络数据或发送缓冲区可用 - 锁操作（Locking）
例如std::mutex的lock()，等待其他线程释放锁
数学上可以描述阻塞调用的行为：在实时关键路径中，如果 的时间不可预测，则整个系统不可确定（non-deterministic）。
while (true) {
// 等待获取锁（可能阻塞）
std::lock_guard<std::mutex> lock(m);
// 处理队列中未知数量元素
while (!q.empty()) {
const auto c = q.front();
Process(c);
q.pop();
}
// 等待下一次迭代
}
解释：
std::lock_guard的构造函数会阻塞直到获取锁- 内部 while 循环依赖
q.empty()- 如果队列为空，线程仍可能循环等待
- 处理数量未知，执行时间不可预测
因此整个循环是阻塞调用示例，不适合实时或关键路径。
std::mutex m;
std::queue<char> q;
std::lock_guard<std::mutex> lock(m);
if (!q.empty()) {
// 只在队列非空时处理
}
说明：
- 减少持锁时间：只检查队列并处理存在元素
- 避免无限等待：如果队列为空，则立即返回
例如 Boost 提供的 SPSC（Single Producer Single Consumer）队列：
boost::lockfree::spsc_queue<MyType> q(42);
if (q.read_available() > 0) {
// 处理元素
}
特点：
- 非阻塞：读取元素不会等待生产者
q.read_available()返回可用元素数- 队列容量固定（42 个元素），不会动态扩展
数学上可表示：即整个队列访问在运行阶段不会阻塞线程。
Boost 提供的 consumer 接口：
while (true) {
w.consume_all(Process);
}
或
while (true) {
w.consume_one(Process);
}
consume_allconsume_one- 都是非阻塞（lock-free 或 busy-wait）
- 避免线程被挂起
- 可预测性高
数学上： - 对于 在循环运行阶段：
- 对队列长度 ，处理时间为：
可预测且有限。
阻塞调用（Blocking Calls）是关键路径系统的性能隐患：
- 文件 I/O / 网络 I/O / 锁操作可能阻塞线程
- 阻塞会导致系统不可预测，破坏实时性
避免策略：
- 尽量减少锁的持有时间
- 使用无锁队列 / lock-free 数据结构
- 非阻塞轮询或消费者模式
- 固定容量队列，避免动态分配
目标：
C++ 的 Zero-Overhead Principle（零开销原则）是设计 C++ 高性能库和抽象的重要理念：
- 你不使用的功能不收费
- 即：如果你没有用某个特性，就不会有额外运行时开销。
- 你使用的功能效率与手写代码相当
- 即：抽象层不会比手动写的代码慢。
数学上可以理解为：}
return false;
- 遍历所有元素
- 显式索引访问
- 可预测，效率高，但代码冗长
C++ 风格算法（零开销抽象）：
const auto iter = std::find_if( statuses.begin(), statuses.end(), [&](const auto &status){ return status.id == id; } ); if (iter != statuses.end()){ return iter->value; } return std::nullopt;分析：
- 使用 标准库算法
std::find_if - 使用 lambda 表达式 进行条件判断
- 不产生额外开销（编译器会内联 lambda）
- 返回
std::optional表示可能存在或不存在
数学上可表示：
核心思想：高层抽象不牺牲性能，符合 Zero-Overhead 原则。
注意事项：
std::unique_ptr通常是首选，用于表示 独占所有权- 但它不是“万能钥匙”，在与 C/C++ 旧接口或第三方库交互时需要特别处理
template <class T> void C_Cpp_Legacy_func(T* ptr){ // 仅使用原始指针，不转移所有权 // do sth with ptr }- 不接管指针的所有权
- 调用者仍然负责释放内存
- 安全调用：
auto ptr = std::make_unique<int>(42); C_Cpp_Legacy_func(ptr.get()); // 只传递裸指针，不释放数学上表示：
template <class T> void C_Cpp_3rdParty_Func(T* ptr){ // 函数接管资源所有权 // do sth with ptr delete ptr; ptr = nullptr; }- 函数接管指针所有权
- 调用者需释放管理权（不能再 delete）
- 安全调用：
C_Cpp_3rdParty_Func(ptr.release());解释：
ptr.release()放弃unique_ptr的管理权- 返回裸指针给函数，由函数 delete
- 避免重复释放（double free）
数学上表示：- 保证了 资源安全释放（RAII）
- 避免内存泄漏与 double free
- 智能指针 + release/get 配合不同函数，既安全又高效
C++ 零开销抽象的关键点：
- Zero-Overhead Principle：
- 未使用 → 不增加开销
- 已使用 → 效率与手写代码相同
- 标准库算法 + lambda：
- 可替代手写循环，零开销
- 智能指针：
unique_ptr表示独占所有权.get()→ 不转移所有权.release()→ 转移所有权
- RAII + 所有权语义：
- 自动管理资源
- 安全、可预测、零额外开销
数学抽象总结：
在安全关键系统（例如医疗机器人、嵌入式控制系统）中，安全、性能、正确性、灵活性和成本之间存在权衡（trade-offs）。
- 在关键路径中 避免动态内存分配（DMA） 和 异常抛出，可能会牺牲部分性能。
- 性能本身是相对的：例如 250 Hz 的控制循环
- 对某些应用来说很快
- 对其他应用可能太慢
- 因此，需要 量化性能影响：
结论：在性能和安全之间，必须通过 测量和表征测试（characterization） 做出合理取舍。
- 一般来说，更安全的代码通常更正确
- 使用静态分析工具（static analysis）
- 可能要求重写代码以满足规则
- 这可能引入新的 bug
- 动态分析工具（dynamic analysis）
- 可能改变代码行为，从而影响正确性
- 性能下降也可能间接影响正确性
数学上可以理解为：
安全措施增强了正确性，但也可能带来副作用，需要权衡。
- 避免不安全的构造可能降低灵活性
- 使用更多封装类型（wrapper types）、严格类型检查、强封装
- 增加了安全性
- 同时限制了代码灵活性
- 总体上，更小心、更安全的设计通常意味着 灵活性降低
数学上：
安全与灵活性通常存在反向关系。
- 为了实现安全，需要大量资源：
- 工程时间（Engineering hours）
- 开发和测试基础设施
- 工具、流程、规范都增加了成本
数学上可以表示：
安全是有代价的，但在医疗或嵌入式领域，这是必要投入。
- 构建安全的复杂医疗机器人非常困难
- 标准和法规是必要的，但不足以保证安全
- 软件是医疗设备故障的重要因素
- 单靠测试不足
- 应该“失败但安全地失败”（Fail but fail safely）
- C++ 的安全性依赖于：
- 强烈的安全文化
- 稳健的架构设计
- 有效的工具链
- 严格的开发流程
- 没有简单的解决方案
- 所有安全设计都需要在性能、正确性、灵活性、成本等方面做出权衡
数学上可以抽象为：
- 所有安全设计都需要在性能、正确性、灵活性、成本等方面做出权衡
最终，权衡（trade-offs）不可避免，关键是理解各个因素之间的相互作用，并做出合理选择。
- 即：抽象层不会比手动写的代码慢。
