虾球xz
虾球xz

CppCon 2014 学习:Defensive Programming Done Right.

这段摘要讲的是：

  • 在组件化开发中，每个开发者负责让自己写的软件易懂且好用，且不易被误用。
  • 常见误用之一是调用库函数时未满足前置条件，导致未定义行为。
  • 未定义行为的契约（contract）不一定不好，很多工程上也许是最佳选择。
  • 大多数人认为库检测到前置条件违反时不应默默继续，但具体怎么处理可能有不同意见。
  • 验证前置条件需要额外的运行时代码，增加代码量会影响速度，有人认为不应强制库用户为冗余检查买单。
  • 是否及如何验证前置条件、检测违规后如何处理，最好由应用程序自身决定（即“main”的拥有者决定）。
  • 该演讲提出“Defensive Programming Done Right”，介绍设计契约（Design-By-Contract，DbC）和防御式编程（Defensive Programming，DP）的基础概念。
  • 讲解如何将防御式编程机制内置于库，使应用程序能灵活选择防御检查的运行时预算（无、部分、大量）及违规时的动作（终止、抛异常、自旋等）。
  • 还涉及现代编译器、链接器、二进制兼容性以及违反单一定义规则（one-definition rule）在混合构建中的影响。
  • 最后介绍“负向测试”策略和测试工具，确保防御检查在组件测试中能正确捕捉和报告违约使用。

大规模 C++ 软件开发中面临的核心问题：

主要挑战：

  1. 逻辑与物理复杂性交织
    大规模 C++ 软件包含许多微妙的逻辑和物理方面的问题（如语义、状态、构建依赖、ABI等），处理起来很复杂。
  2. 需要模块化设计能力
    必须具备将逻辑功能清晰隔离并模块化为细粒度的物理组件的能力（例如，一个个小的 .cpp 文件和头文件、库）。
  3. 精确定义逻辑行为 + 管理物理依赖
    设计者不仅要精确描述组件的行为契约（接口/语义），还要管理其与其他底层组件之间的物理依赖（比如头文件依赖、链接依赖）。
  4. 即便组件本身完美，也容易被误用
    就算一个组件设计良好、文档齐全、测试充分，如果调用者（client）用错了它，整个系统依然会出错。

总结一句话：

大型 C++ 软件要求不仅要正确实现组件，还要通过良好的设计和防御性机制防止客户端误用，否则系统仍会“broken”。

主要聚焦在如何构建逻辑上和物理上健壮的组件、接口及其契约。

主要目标如下：

  1. 介绍如何设计/说明健壮组件
    • 包括：
      • 逻辑行为的定义（函数应该做什么）
      • 物理结构的设计（代码、模块、依赖）
      • 合同（contract）：即组件的前置条件、后置条件、不变式等
  2. 强调清晰文档化行为的重要性
    • 特别是：明确哪些行为是定义的，哪些是未定义的
    • 这样做有助于使用者正确理解和使用组件
  3. 解释未定义行为的工程价值
    • 虽然“未定义行为”通常被视为危险，但在适当使用下可以带来好处：
      • 降低初始开发成本
      • 简化测试与维护
      • 提高运行效率（无需添加额外检查）
      • 减小代码体积
  4. 展示如何利用未定义行为进行错误检测
    • 利用 bsls_assert 设施（Bloomberg 的断言机制）
    • 当客户端代码违背前置条件时，可以通过断言立刻发现错误

总结一句话：

本讲座通过DbC（契约式设计）+ 防御式编程 + 明确的接口契约，教你如何构建既高效又健壮的 C++ 库组件，并说明为何适度利用“未定义行为”是一种工程上的权衡与优化。

大纲（Outline），主要介绍了五个内容模块，涵盖从物理设计到负向测试的全过程，具体如下：

1. Brief Review of Physical Design（物理设计简述）

  • 介绍组件在大型 C++ 系统中的组织方式（模块、文件、依赖等）。
  • 如何将逻辑功能映射到物理结构（如 .h 和 .cpp 分离、命名空间、层次结构等）。
  • 目的：实现良好的封装、解耦与重用性。

2. Interfaces and Contracts（接口与契约）

  • 接口（Interface）：函数或类对外暴露的调用方式。
  • 契约（Contract）：调用接口前提下应满足的条件（如“参数不能为 null”）。
  • 关键点：区分语法和语义（Syntax vs. Semantics）：
    • 语法正确 ≠ 合同满足（程序可以编译，但未必安全运行）
    • 定义行为 vs. 未定义行为（Defined vs. Undefined Behavior）

3. ‘Good’ Contracts（什么是“好”的契约）

  • 什么是好用、可维护、安全的接口契约？
  • 介绍**Defensive Programming（防御式编程）**思想：
    • Narrow Contracts（窄契约）：假定调用方完全负责满足前置条件（高效，但危险）
    • Wide Contracts（宽契约）：组件尽量容忍错误输入（更安全，但更复杂）

4. Implementing Defensive Checks（实现防御式检查）

  • 如何在实现中添加契约检查，而不会影响生产效率？
  • 介绍 Bloomberg 提供的 bsls_assert：
    • 一种可配置的运行时断言机制
    • 支持应用自定义：是否启用断言、如何响应（抛异常、终止、忽略）

5. Negative Testing（负向测试）

  • 使用 bsls_asserttest 组件验证断言是否能在错误用法下触发
  • 目的：
    • 确保防御性代码工作正常
    • 避免“沉默失败”
  • 这是一种面向契约的测试方法，验证组件对“坏用法”的反应

总结

这个大纲展示了如何从系统设计、接口约定，到实现防御、测试验证，全流程构建健壮、可控、可测的 C++ 组件库。

C++ 组件化开发中“逻辑设计（Logical Design）”与“物理设计（Physical Design）”的区别：

Logical Design（逻辑设计）

  • 关注：程序的行为与职责分配
  • 包括：
    • 类（Classes）：封装数据和行为
    • 函数（Functions）：完成具体操作
    • 接口、契约（Interface / Contract）
  • 表示“我们希望系统如何工作”
示例：
class Account {
public:
    void deposit(double amount);
    void withdraw(double amount);
};

Physical Design（物理设计）

  • 关注：程序的组织结构和部署方式
  • 包括：
    • 头文件（.h / .hpp）
    • 实现文件（.cpp）
    • 静态库、动态库（.a, .so, .dll）
  • 表示“我们如何组织代码和构建产物”
示例：
account.h         // 声明类 Account
account.cpp       // 实现类 Account 的方法
libbanking.a      // 编译出的静态库，供其他程序链接使用

总结对比

特性 Logical Design Physical Design
本质 行为的设计 结构和文件的组织方式
关注点 类、函数、契约 文件、模块、编译边界
作用范围 面向设计者和维护者 面向构建、发布与部署
示例 类 Account 的职责划分 .h/.cpp 的划分与依赖

逻辑内容被组织进物理层次结构中

拆解说明：

  • 逻辑内容（Logical content）：
    • 指的是类（classes）、函数（functions）、接口（interfaces）、契约（contracts）等软件设计中抽象的逻辑结构。
    • 例如：一个 Account 类负责账户操作逻辑，Transaction 类负责交易逻辑。
  • 物理层次结构（Physical hierarchy）：
    • 指的是文件系统结构：头文件（.h）、源文件（.cpp）、模块目录、库文件等。
    • 比如：
      /banking/
  ├── account.h
  ├── account.cpp
  ├── transaction.h
  └── transaction.cpp

核心观点：

  • 在实际开发中，我们必须把逻辑上的类和函数映射成物理结构中的文件和模块。
  • 这些映射形成了一个层次结构（例如组件 > 包 > 模块 > 系统）。

示例（可视化映射）：

逻辑设计（类、接口） 物理实现（文件、路径）
Account 类 banking/account.h, account.cpp
TransactionProcessor 类 banking/transaction_processor.cpp
BankInterface 抽象接口 interfaces/bank_interface.h
总结：逻辑设计是“我们想怎么组织功能”，物理设计是“我们怎么组织代码文件来支持这些功能”。好的物理设计能清晰反映出背后的逻辑结构，从而提升可维护性、可测试性与可扩展性。

C++ 组件的标准物理结构（Uniform Physical Structure of a Component），即一个组件（component）在实际文件系统中的组织方式。

一个组件（component）通常包含三个文件：

文件名 说明
component.h 公共头文件，声明 API，供其他组件使用。
component.cpp 实现文件，实现 .h 中声明的函数。
component.t.cpp 测试驱动程序（test driver），测试该组件。

示例结构：

component/
├── component.h      // 声明接口
├── component.cpp    // 实现接口
└── component.t.cpp  // 单元测试（test driver）

为什么这样设计？

  1. 一致性：每个组件都有相同的结构，便于理解、维护、自动化构建。
  2. 分离关注点：
    • .h 文件用于声明 —— 提供接口，不暴露实现。
    • .cpp 文件用于定义 —— 封装实现细节。
    • .t.cpp 文件用于验证 —— 提供组件级测试。
  3. 可测试性强：每个组件带有专属的测试文件，易于进行独立验证。

小结：

这一结构体现了 “组件级开发” 的核心理念，即将逻辑功能模块化，并映射为清晰、可复用、可测试的物理单元。

这部分讲的是 组件之间的逻辑关系（Logical Relationships） 和 由逻辑关系产生的依赖层级（Implied Dependency & Level Numbers）。它通过一个示例图（围绕 Shape、Polygon、PointList 等）逐步引出模块之间的各种依赖关系类型。

核心思想总结：

① 四种主要的逻辑关系类型：

关系类型 含义说明
Is-A 继承关系（如：Polygon 是一个 Shape）
Uses-in-the-Interface 在接口中使用（如：函数参数或返回值中引用某类型）
Uses-in-the-Implementation 在内部实现中使用（如：函数内部临时变量引用某类型）
Uses-in-name-only 仅仅出现在注释或文档中，编译器无法察觉，但读者可以感知（例如注释中提到某类）

② Implied Dependency（隐式依赖）：

这些逻辑关系会导致不同组件在 物理构建和链接 上产生依赖。例如：

  • Polygon 在接口中用到 PointList，意味着其 .h 头文件需要包含 PointList；
  • 如果 Polygon 在实现中用到 PointList_Link，那就是实现层面的依赖。
    所有这些关系，不管编译器是否强制要求，都影响系统的可维护性、耦合度和构建顺序。

③ Level Numbers（层级编号）：

通过分析依赖图，我们可以为每个组件打上“层号”，表示它在整个系统中依赖链的深度：

组件 层级号（Level） 说明
Point, PointList_Link 1 基础组件，无依赖
PointList 2 依赖 Point 与 PointList_Link
Polygon 3 依赖 PointList
Shape 1 无依赖（或者视作抽象基类）
这种 “层级编号” 有助于：
  • 理解组件初始化顺序
  • 管理构建依赖
  • 拆分库文件（.so 或 .a）
  • 控制耦合度

小结：

逻辑关系 → 物理依赖 → 构建顺序 → 设计质量。

模块间的关系不仅影响代码结构，也深刻影响构建流程和团队协作。越早在设计阶段建立清晰的依赖关系，后期的维护成本就越低。

这部分是对刚才“Physical Design 简要回顾”的总结性提问，目的是确保读者能掌握以下三个核心问题：

1️ What distinguishes Logical from Physical Design?

  • Logical Design（逻辑设计）：
    • 关注抽象结构，如类（Class）、函数（Function）、接口（API）设计。
    • 体现为“谁用谁”、“继承关系”、“组合关系”等。
    • 是从软件功能角度进行的设计。
  • Physical Design（物理设计）：
    • 关注实现结构，如 .cpp、.h 文件划分，库的组织，编译单元的依赖。
    • 是从代码实现与部署角度进行的设计。
    • 决定了源文件之间的依赖顺序、编译顺序、链接方式等。

2️ How do we infer physical relationships (Depends-On) from logical relationships (e.g., Is-A and Uses)?

  • 每种逻辑关系（如 Is-A、Uses-in-interface、Uses-in-implementation）都可能带来物理依赖（Depends-On）。
  • 举例：
    • 若 Polygon Is-A Shape → 必然在 .h 中包含 Shape.h → Polygon 物理上依赖 Shape。
    • 若 Polygon 的方法参数或返回值包含 PointList → 产生接口依赖 → 物理上依赖 PointList。
    • 即使只是实现细节（e.g., 局部变量用到 PointList_Link），也会导致 .cpp 的依赖。
  • 这些依赖会反映在编译依赖图中，影响构建、测试、重构的难易度。

3️ What are level numbers?

  • Level Number 是一种用于衡量组件在依赖树中深度的指标：
    • Level 1：无任何依赖的底层组件。
    • Level N：依赖于一个或多个 Level < N 的组件。
  • 它们帮助我们：
    • 组织构建顺序（越底层越先编译）；
    • 评估耦合度（越高级越依赖多）；
    • 优化设计（鼓励浅层依赖、避免环依赖）。

总结

问题 核心答案
逻辑 vs 物理设计 抽象结构 vs 实现结构
逻辑关系如何导出物理依赖 Is-A、Uses 关系决定物理文件间的包含和链接
Level Numbers 是什么 用于衡量依赖深度，指导构建与设计

提纲（Outline），概述了要讲解的 5 个核心部分。下面是对每一部分的简要解释，帮助你构建整体理解框架：

1. Brief Review of Physical Design

复习组件物理结构设计：

  • 区分逻辑设计 vs 物理设计
  • 组件如何组织成 .h、.cpp、.t.cpp 文件
  • 理解依赖关系与层级（Level Numbers）

2. Interfaces and Contracts

接口与契约：

  • 明确区分语法（Syntax）与语义（Semantics）
  • 强调接口不仅是函数声明，还包括调用者必须遵守的前提条件（Preconditions）
  • 引出 “undefined behavior”（未定义行为） 概念，说明何时可以接受它，并如何文档化它

3. ‘Good’ Contracts

什么是好的契约？

  • 引入 Defensive Programming（防御式编程）：避免错误使用库导致程序崩溃或行为不可预期
  • 区分：
    • Narrow Contract：要求使用者必须满足严格前提，库假设调用者总是正确的
    • Wide Contract：库自己会检测前提是否满足，具备更强健的容错能力

4. Implementing Defensive Checks

如何实现防御性检查：

  • 使用 bsls_assert 组件（Bloomberg 自研的断言库）
  • 根据应用需求，灵活设置：
    • 检查开销（性能 vs 安全性）
    • 违反前提的处理策略（abort, throw, log, spin 等）

5. Negative Testing

负向测试（验证契约检查机制）：

  • 使用 bsls_asserttest 组件
  • 测试用例故意违反前提条件，确保断言触发
  • 确保防御性机制确实有效，能够及时发现错误使用

总结表格：

模块 内容简介
1. Physical Design 理解组件的结构与依赖
2. Interfaces & Contracts 明确前提条件与未定义行为
3. Good Contracts 学会区分并选择 Narrow/Wide Contract
4. Defensive Checks 用断言检测并防止错误使用
5. Negative Testing 验证断言机制的可靠性

这里是在讲解 接口（Interface） 和 契约（Contract） 的概念，并用一个具体的函数例子来说明。

2. Interfaces and Contracts

Interface vs Contract
  • 接口（Interface）：指的是函数、类或组件对外暴露的可见部分，比如函数的签名（参数、返回值类型）和可调用的成员函数。
  • 契约（Contract）：是对接口的补充说明，明确调用该接口时必须满足的前提条件（preconditions）、函数行为的语义（比如对输入参数的要求，输出结果的保证等），以及函数的副作用。
举例：函数接口与契约

函数声明：

std::ostream& print(std::ostream& stream,
                    int level = 0,
                    int spacesPerLevel = 4) const;
  • 接口：函数名、参数类型、默认参数、返回类型。
  • 契约（文档注释中说明）：
    • 功能：格式化该对象到输出流 stream。
    • 参数说明：
      • level：指定缩进等级，负值表示第一行不缩进。
      • spacesPerLevel：每个缩进等级的空格数，负值表示输出在一行，除了初始缩进外无其它缩进。
    • 预期行为：
      • 如果传入的 stream 在调用时无效，函数无任何作用。
    • 返回值：
      • 返回传入的 stream 的引用，方便链式调用。

重点

  • 接口只是“形式”，契约明确“语义”
  • 契约告诉使用者：
    • 在什么条件下调用函数是合法的（preconditions）
    • 函数会做什么（postconditions）
    • 如果违反前提，结果会怎样（undefined behavior 或者异常）

这个部分用一个类的例子来说明接口和契约的区别和关系。

2. Interfaces and Contracts — 类的例子

类接口（Public Interface）
class Date {
    // 该类表示一个有效的日期，范围是 0001/01/01 到 9999/12/31。
public:
    Date(int year, int month, int day);
    // 构造一个有效的日期对象。
    // 预条件（contract）：传入的 year, month, day 必须表示一个有效日期，
    // 即在范围 [0001/01/01 .. 9999/12/31] 内，否则行为未定义。
    Date(const Date& original);
    // 拷贝构造函数，创建一个值与 original 相同的 Date 对象。
};
重点
  • 接口：
    • 函数签名（构造函数），参数类型，成员可见性（public）等。
  • 契约：
    • 具体行为说明：比如构造函数的参数必须满足什么条件（预条件），否则行为未定义。
    • 说明了有效的日期范围，是调用者必须遵守的约束。

总结

  • 接口定义了使用该类的“形状”和“形式”。
  • 契约明确了使用该接口时的语义规则和假设。
  • 契约不仅告诉你函数做什么，也告诉你“在什么条件下调用是合法的”。
  • 未满足契约的调用可能导致未定义行为。

2. Interfaces and Contracts — 组件的“公共接口”

示例：Date 组件的公共接口包括：

  • 类声明（class Date），公开成员函数（构造函数等）
  • 非成员操作符重载：
bool operator==(const Date& lhs, const Date& rhs);
// 判断两个 Date 对象是否相等（年、月、日都相同返回 true）
bool operator!=(const Date& lhs, const Date& rhs);
// 判断两个 Date 对象是否不等（只要年、月、日有一项不同返回 true）
std::ostream& operator<<(std::ostream& stream, const Date& date);
// 按 "yyyy/mm/dd" 格式把日期写入输出流，并返回该流的引用

要点：

  • 这些函数和操作符是 组件的公共接口 的一部分，调用者通过它们与 Date 组件交互。
  • 接口的定义清楚说明了：
    • 函数做什么（语义）
    • 参数和返回值的类型和含义
  • 这是组件提供给使用者的约定（契约的一部分），保证了正确使用时的行为一致性。

总结

  • 接口：函数签名 + 语义说明
  • 契约：接口上的具体要求（参数范围、行为保证等）
  • 操作符重载让组件能更自然地被使用，符合习惯（比如比较和打印）

函数的前置条件（Precondition）和后置条件（Postcondition），特别是用 sqrt 函数作为示例：

2. Interfaces and Contracts

Preconditions and Postconditions (前置条件与后置条件)

示例函数：

double sqrt(double value);
// 返回指定 value 的平方根。
// **前置条件**：必须保证 'value >= 0'。
// 否则，行为未定义。

关键点：

  • 前置条件（Precondition）：调用该函数前必须满足的条件。
    • 例如这里 value >= 0。
    • 这是对输入的限制，保证调用函数时输入是合法的。
  • 后置条件（Postcondition）：函数调用结束后应保证的条件或函数返回的结果。
    • 这里是函数返回 value 的平方根。
  • 行为未定义：如果不满足前置条件，函数的行为可能是崩溃、异常、或者错误结果，调用者不能依赖函数的结果。

为什么重要？

  • 保证接口使用正确：调用者必须遵守前置条件，否则不保证程序正确。
  • 接口契约的一部分：清晰表达函数责任和调用者责任。

总结

  • 前置条件：函数要求调用者满足的条件（输入有效性约束）。
  • 后置条件：函数保证的输出或状态。

这部分补充了前置条件和后置条件在**对象方法（Object Method）**中的含义，核心要点总结如下：

2. Interfaces and Contracts

Preconditions and Postconditions for Object Methods

前置条件（Preconditions）：

  • 必须对对象的状态和方法的输入参数同时成立。
  • 如果不满足，方法的行为就是未定义的（Undefined Behavior）。
  • 也就是说，调用者必须保证对象处于正确的状态，且输入有效。

后置条件（Postconditions）：

  • 当且仅当前置条件全部满足时，方法必须保证的一些行为或结果。
  • 这些是对象状态和方法输入共同决定的结果。

额外补充：

  • Essential Behavior（基本行为） 是后置条件的超集。
  • 它包括行为保证，例如方法的运行时间复杂度等性能特征。

小结：

条件类型 作用对象 含义
前置条件 对象状态 + 方法输入 调用前必须满足，否则行为未定义
后置条件 对象状态 + 方法输入 满足前置条件时，方法必须保证的行为或结果
基本行为 (Essential Behavior) 后置条件的超集 还包括性能保证等更广泛的行为规范
这部分强调了接口契约不仅仅是函数输入输出的约束，还包括对象状态的一致性和性能保证。

这部分内容核心在区分 Defined Behavior、Essential Behavior、Undefined Behavior 以及它们在接口契约中对前置条件和后置条件的影响。

核心概念解析

类型 含义 例子/说明
Defined Behavior 行为被明确规定（specified），实现中必须做到的行为 比如 print 方法定义了如何格式化输出，明确说明了参数含义和返回值。
Essential Behavior 核心的、必须保证的行为（是 Defined Behavior 的一部分） 例如返回流引用、正确格式化输出、保持指定的缩进等。
Undefined Behavior 违反前置条件，行为不确定，可能导致程序崩溃或不可预测的结果 Date 构造函数传入无效日期时行为未定义。
Defined but not Essential Behavior 明确定义但非核心或非必需保证的行为 实现细节依赖或结果的非关键特性，比如输出中额外空白的处理、某些性能细节等。
Unspecified and Implementation Dependent 行为明确但具体实现可以不同，非必需保证 输出格式中的某些细节可能因实现不同而不同，但不影响功能。

例子详解

print 方法（Defined & Essential Behavior 示例）
std::ostream& print(std::ostream& stream,
                    int level = 0,
                    int spacesPerLevel = 4) const;
// 作用：将对象格式化输出到指定的输出流 `stream`。
// 参数说明：
// - level: 缩进级别（负值时，首行不缩进）
// - spacesPerLevel: 每级缩进空格数（负值时，输出为一行，不缩进）
// 返回值：返回传入的流引用。
// 约定：如果输入的 `stream` 无效，操作无效，但不导致错误。
// 行为保证：格式化和缩进符合描述，返回流引用。
// 未定义行为：若调用前 `stream` 状态异常等。
  • 这是Defined和Essential行为，因为它定义了方法核心的行为和效果，且是调用者依赖的保证。
Date 构造函数（Undefined Behavior 示例）
Date(int year, int month, int day);
// 创建有效日期，行为未定义除非year/month/day有效且在范围内[0001/01/01 .. 9999/12/31]。
  • 若传入非法日期，行为未定义，调用者必须遵守前置条件。

总结

  • 前置条件不满足时，行为未定义（Undefined Behavior），程序不保证任何事情。
  • 行为必须被明确定义（Defined Behavior）且核心行为为Essential Behavior，保证接口使用时的可靠性。
  • 某些行为可能定义但非核心，允许实现细节差异。
  • 接口契约通过区分这些行为类型，明确了调用者和实现者的责任边界。

这里主要强调了 (Object) Invariants（对象不变式） 和它们与 前置条件（Preconditions） 以及 后置条件（Postconditions） 的关系。

核心要点整理：

1. 对象不变式（Object Invariants）是什么？
  • 是对象状态必须始终满足的条件。
  • 在对象的整个生命周期中，不论何时观察对象，它的状态必须保持这些不变式为真。
  • 例如，Date 类的对象不变式就是日期必须有效，必须在 0001/01/01 到 9999/12/31 范围内。
2. 前置条件（Preconditions）与对象不变式的关系
  • 前置条件确保传入数据和方法调用时的对象状态符合不变式要求。
  • 例如，构造函数 Date(int year, int month, int day) 的前置条件是传入的年月日必须构成有效日期。
  • 违反前置条件时，行为是未定义的（undefined behavior），对象不保证正确状态。
3. 后置条件（Postconditions）与对象不变式的关系
  • 后置条件保证方法执行结束后，对象仍满足不变式。
  • 构造函数成功后，创建的 Date 对象必须满足不变式，即表示有效日期。

举个例子

class Date {
public:
    Date(int year, int month, int day);
    Date(const Date& original);
    // ...
};
  • 前置条件：传给构造函数的 year/month/day 必须是有效日期。
  • 后置条件：构造函数完成后，Date 对象必须表示一个有效日期（满足不变式）。
  • 如果前置条件未满足，行为未定义，Date 对象可能处于非法状态。

这样设计的好处

  • 明确对象有效状态范围，保证代码的健壮性。
  • 利用前置和后置条件控制错误输入，减少隐藏的bug。
  • 方便维护和扩展，后续方法只需确保不变式不被破坏。

Design by Contract（设计契约，简称 DbC），它是软件设计中的一种方法论，核心思想是：

Design by Contract (DbC) 核心

“If you give me valid input (including valid state), I will behave如约而至；否则，行为不保证。”

这句话的意思是：

  • 只要调用者满足前置条件（输入数据和对象状态有效），被调用者就保证按照合同执行功能（后置条件和不变式保持正确）。
  • 反之，若前置条件不满足，调用结果不可预测（可能崩溃、异常、错误结果等）。

设计契约的文档包含五个方面：

  1. What it does（功能说明）
    说明方法做了什么。
  2. What it returns（返回值）
    说明方法返回什么。
  3. Essential Behavior（核心行为）
    保证前置条件满足时，方法必然完成的行为和状态。
  4. Undefined Behavior（未定义行为）
    说明违反前置条件时，行为不保证。
  5. Note that…（注意事项）
    可能包含特殊说明、性能保证、异常安全等额外信息。

这个方法的好处

  • 清晰职责：调用者负责保证输入合法，方法负责实现功能。
  • 降低耦合：双方明确责任边界。
  • 易于测试和维护：可以有针对性地验证前置条件和后置条件。
  • 增强代码文档：方法行为和限制明确可见。

你这部分讲的是 Design by Contract（设计契约） 中的 验证（Verification），主要内容包括：

设计契约的验证要点

  1. Preconditions（前置条件）
    • 调用者负责满足前置条件。
    • 验证方法：
      • RTFM（Read the Manual），即“读文档”，确保使用正确。
      • 在调试模式或安全模式下，使用断言（assert）来检测输入和状态是否合法。
  2. Postconditions（后置条件）
    • 由组件的单元测试（Component-level test drivers）来验证方法执行后是否满足预期的后置条件。
  3. Invariants（不变式）
    • 对象的不变条件必须在对象生命周期内始终保持成立。
    • 通常在析构函数（destructor）中断言检查不变式，确保对象销毁时状态有效。

额外说明

  • 断言（assert）通常只在调试或安全模式开启，生产环境可关闭以提升性能。
  • 断言帮助及时发现违反契约的错误，方便调试。
  • 以后讲座的第四部分会详细介绍断言和安全模式。

这些问题是设计契约（Design-by-Contract, DbC）这部分想要回答的核心内容，帮助我们全面掌握设计契约的理念和实践：

设计契约中要回答的问题总结：

  1. 设计契约的核心理念是什么？
    • 通过明确的契约（合同）定义调用者和被调用者之间的责任和保证，从而提高代码的可靠性和可维护性。
  2. 接口（Interface）和契约（Contract）有什么区别？
    • 接口描述的是功能的可用性（比如函数签名），
    • 契约则明确规定输入输出条件和行为保证（前置条件、后置条件、不变式）。
  3. 什么是前置条件、后置条件和不变式？
    • 前置条件：调用者必须满足的条件。
    • 后置条件：被调用者保证执行后成立的条件。
    • 不变式：对象生命周期中始终保持为真的条件。
  4. 什么是“本质行为”（essential behavior）和“未定义行为”（undefined behavior）？
    • 本质行为是契约中承诺的行为。
    • 未定义行为是在契约前置条件不满足时，行为不保证，可能出现异常或崩溃。
  5. 即使违反了一个或多个前置条件，代码是否必须保持不变式？
    • 不一定；违反前置条件时，行为未定义，但良好设计应尽量保证不变式不会被破坏。
  6. 如何记录函数的契约？
    • 文档中明确说明“做什么”、“返回什么”、“前置条件”、“后置条件”、“不变式”以及注意事项。
  7. 如何确保后置条件被满足？
    • 通过单元测试和断言验证。
  8. 如何测试不变式是否被保持？
    • 在构造、修改、销毁对象时使用断言检查不变式，确保其持续成立。
      这些问题一起构成了设计契约体系的理论基础和实践指南，帮助我们编写健壮、易维护的代码。

“防御式编程（Defensive Programming，DP）”的定义、利弊，以及它要防御的对象。帮你总结和扩展一下：

防御式编程（DP）简介

定义：
防御式编程是指在代码中加入冗余的运行时检查，用来检测和报告程序中的缺陷（bugs），但不负责“处理”或“隐藏”这些缺陷。它主要是为了在开发或测试阶段尽早发现问题。

防御式编程的优缺点

  • 优点：
    • 能及早发现bug，有助于定位和修复问题。
    • 提高代码的健壮性。
  • 缺点：
    • 增加运行时开销（性能损失）。
    • 可能导致代码臃肿，影响代码简洁性。

防御式编程和设计契约（DbC）的比较

  • 防御式编程和设计契约不冲突，就像“你是坐公交车去学校，还是带午餐”一样，选择因场景而异。
  • DbC强调：只要前置条件满足，函数行为一定可靠；违反前置条件时，行为未定义。
  • DP强调：即使前置条件被破坏，也会尽力检测和报告错误。

防御式编程防御的对象

  1. 我们用到的外部软件的bug
    • 比如第三方库或底层系统组件的缺陷。
  2. 我们自己实现中引入的bug
    • 自己写代码时无意间的错误。
  3. 客户的误用
    • 用户调用接口时传入无效参数或错误操作。
      #这部分内容在讲“窄契约（Narrow Contracts）”和“宽契约（Wide Contracts）”的区别，以及它们对程序行为的影响和设计选择。
      我帮你总结一下重点：

窄契约 (Narrow Contracts) vs 宽契约 (Wide Contracts)

窄契约的特点

  • 严格的前置条件，调用者必须确保输入满足契约要求，否则行为未定义。
  • 典型例子：strlen(nullptr) 是未定义行为，程序不保证什么结果。
  • 通常在**调试模式（debug mode）**使用断言（assert）检测违反契约的情况。
  • 优点：接口简洁，代码性能好，明确责任边界。
  • 缺点：如果调用者传入错误数据，可能导致程序崩溃或不确定行为。

宽契约的特点

  • 允许更多输入，包括不完全满足前置条件的情况，代码负责处理错误输入并返回状态码或做适当响应。
  • 典型例子：strlen(nullptr) 返回0（示例中假设）。
  • 优点：更健壮，减少因误用导致的程序崩溃。
  • 缺点：
    • 代码更复杂，运行时检查增加开销。
    • 容易掩盖潜在错误（bug），因为错误输入被“悄悄处理”了。
    • 宽契约等于接口变“宽”，增加维护难度。

例子说明

  • strlen(const char *s)：
// 窄契约：
// 假设 s 不能为空，调用者负责保证
size_t strlen(const char *s) {
    assert(s);  // 只在调试模式下检查
    // 计算长度...
}
  • 宽契约示例：
// 宽契约：
// 允许 s 为 nullptr，返回0表示空字符串
size_t strlen(const char *s) {
    if (!s) return 0;
    // 计算长度...
}

这里宽契约容易掩盖错误，比如用户本来不应该传 nullptr，传了却没报错。

关于接口设计的讨论

  • 是否返回状态码？
    返回状态码属于宽契约，意味着函数本身负责检测和处理错误输入。
    不返回状态码，函数假定调用者遵守契约，是窄契约。
  • 行为未定义意味着什么？
    行为未定义的情况下，程序可以崩溃、异常或者表现任意结果。窄契约强调这种“风险”，要求调用者自律。
  • 是否应该包含行为未定义的行为到合同中？
    如果行为是合同的一部分，就是定义行为，不是未定义行为了。

实际应用

  • 标准库如 vector::operator[] 是窄契约，未检查越界，行为未定义。
  • vector::at() 是宽契约，检查越界，抛出异常。

1. 行为未定义时怎么办？

以 vector::operator[](int idx) 举例：

  • 行为未定义：当 idx 超出范围，行为是未定义的。
  • 这个未定义行为的具体表现，往往依赖于编译模式（debug模式可能断言崩溃，release模式可能无检查直接越界访问）。
  • 因此，窄契约强调“调用者保证参数正确”，否则后果自负。
    相对的：
  • vector::at(int idx) 是宽契约，检查越界，越界时抛异常，定义行为更明确。

2. 函数参数越界时，行为是否应该定义？

以 void insert(int idx, const TYPE& value); 举例：

  • 问题是： 当 idx < 0 或 idx > length() 时，应该怎么办？
  • 一些设计可能选择“自动修正索引”：
    if (idx < 0) idx = 0;
if (idx > length()) idx = length();
    甚至用模运算循环索引，但这属于宽契约。
  • 而讲究窄契约的设计，答案是“不应该定义这些情况的行为”，而是断言（assert）崩溃提示错误。
    void insert(int idx, const TYPE& value) {
    assert(0 <= idx && idx <= length());
    // ...
}
  • 这鼓励调用者保证正确传参，不掩盖错误。

3. 窄契约应适度，不能太窄

举 replace(int index, const TYPE& value, int numElements); 例子：

  • 如果 index == length() 并且 numElements == 0，这其实是合理的调用，代表不做任何替换（插入或删除0个元素）。
  • 所以对这个边界条件，契约应该允许，即使这看起来像越界，也不应该断言失败。
  • 这种“适度宽容”是“适度窄契约（Appropriately Narrow Contracts）”，既保持了接口的严格性，也能处理合理边界情况。

总结

设计原则 含义 例子
窄契约 (Narrow) 明确断言，行为未定义时直接崩溃，调用者负责保证参数合法 operator[]，insert参数越界断言失败
宽契约 (Wide) 函数内部处理错误输入，返回状态或修正参数，代码更健壮但可能掩盖错误 at()越界抛异常，strlen(nullptr)返回0
适度窄契约 (Appropriately Narrow) 对合理的边界值允许行为，保持契约的实用性和健壮性 replace(index == length(), numElements == 0)允许不报错

契约（Contracts）与异常处理（Exceptions）之间的关系，重点如下：

1. 前置条件（Preconditions）决定后置条件（Postconditions）

  • 如果函数在前置条件成立时无法满足其后置条件，函数就不能正常返回。
  • 换句话说，函数不能偷偷“打马虎眼”——要么正常完成，要么抛异常（或终止程序）。

2. 异常的来源应是硬件限制

  • 函数失败时的原因，应该是硬件资源不足（比如内存不足），而不是程序状态导致的逻辑错误。
  • 这种失败是不可避免且不可修复的，除非换一台更大（更强）的机器。

3. 内存分配失败是唯一合适的异常来源

  • std::bad_alloc 是库中唯一应该抛出的异常（特别是分配器相关的组件）。
  • 这意味着库其他部分应尽量避免抛异常，而是用断言或返回错误码处理逻辑错误。

4. 如果禁用异常，abort() 是合理的替代

  • 在一些不支持异常的环境下，调用 abort() 终止程序是一个可接受的选择，确保不会以错误状态继续执行。

5. 好库组件应当是异常中立的（Exception-neutral）

  • 通过 RAII（资源获取即初始化）技术，确保即使抛出异常也不会导致资源泄露。
  • 库内部不要依赖异常逻辑做太多事情，保持异常透明和健壮。

总结

  • 契约的前提条件保证了函数的正常行为，否则函数应“干脆”失败，不做隐晦处理。
  • 异常只用来表示不可避免的硬件资源问题，逻辑错误由契约断言等方式捕获。
  • 设计库时保证异常中立，能让用户放心使用。

这段话是在列出我们这部分内容要回答的关键问题，主要围绕以下几个主题：

1. 什么是防御式编程（Defensive Programming，DP）？

  • 它是一种编写程序的方法，目的在于增强程序的健壮性，提前检查和处理错误条件，避免程序因无效输入或异常情况崩溃。

2. 什么是窄契约（narrow contract）和宽契约（wide contract）？

  • 窄契约：函数的前置条件严格，一旦不满足就可能导致未定义行为。
  • 宽契约：函数允许更多输入范围，处理更广泛的情况。
  • 例如：
    • std::strlen(0)：是否应该对传入空指针进行合理处理？
    • Date::setDate(int, int, int)：是否应该返回状态码告诉调用者设置是否成功？

3. 未定义行为应该如何处理？

  • 应该如何在组件契约中定义或不定义未定义行为的处理？
  • 是让程序崩溃，断言失败，还是做某种容错处理？

4. 针对具体接口的行为，应该如何定义？

  • operator[](int index) 是否应该检查 index 是否越界（小于0或大于长度）？
  • 如果 index 超出范围，程序应该怎么做？

5. insert(int index, const TYPE& value) 函数在 index 超出合法范围时行为应如何？

  • index 大于长度或小于零时，这种行为是否应该定义？还是让其未定义？

6. replace(int index, const TYPE& value, int numElements) 在 index 等于长度且 numElements 为零时，行为应否定义？

  • 这类边界条件是否应该允许，或者应被视为非法？

总结：

这些问题的核心都在于接口契约的设计——应该严格还是宽松？未定义行为的处理方式？如何平衡易用性和安全性？

如何实现防御性检查（Defensive Checks）以应对客户端错误使用库代码的情况，以及应该由谁来决定这些检查的力度和处理策略。

1. 如果客户端错误使用库代码，应该怎么办？

  • 开发者是否应该因为客户端错误被解雇？
  • 应该更小心？更充分测试？
  • 应该让库自己警告或检测错误，而不是依赖客户端？

2. 作为库开发者，我们应该：

  • 更好地文档化代码？
  • 尝试检测未定义行为？
  • 是否能检测所有未定义行为？（答案是否定的）
  • 在检测客户端错误上，应该花多少CPU时间？选项包括：
    • 少于5%
    • 5%到20%
    • 超过20%，但不超过常数因子
    • “天花板”不限，甚至是 O(log n)、O(n) 等复杂度

3. 如果检测到客户端错误，库该如何响应？

选项包括：

  • 忽略并继续？
  • 正常返回？
  • 立即终止程序？
  • 抛出异常？
  • 等待调试器中断？
  • 或其他自定义处理？

4. 如何作为一个企业决定应对策略？

需要考虑的因素：

  • 软件成熟度（alpha、beta、生产环境）
  • 是否是性能关键型应用
  • 是否有合理的应对方案，比如：
    • 保存客户数据后终止程序
    • 记录错误，放弃当前事务并继续
    • 发送消息通知运维人员并等待处理

5. 谁应该决定防御检查的细节？

  • 库组件开发者
  • 立即使用该库的客户端开发者
  • 应用所有者（负责整个应用，拥有 main 函数）

6. 高层要求

  • 让应用所有者可以方便地指定：
    • 库检测客户端违规行为时应花多少时间
    • 违规行为被检测到时应采取的行动
  • 让库开发者可以方便地在代码中实现配置化（编译时和运行时）的检测机制

使用 bsls_assert 组件实现防御性检查（Defensive Checks）的详细计划和示例，重点在于如何通过宏和失败处理器来检测和处理客户端误用库代码的情况。以下是对内容的理解和总结：

1. 计划（Part I）：提供三种 BSLS_ASSERT 宏*

  • 目标：为库开发者提供三种不同级别的 BSLS_ASSERT* 宏，用于在不同场景下进行防御性检查。
  • 三种宏及默认行为：
    1. BSLS_ASSERT_OPT(EXPR)：
      • 特点：始终激活。
      • 开销：小于 5%（性能影响最小）。
      • 用途：用于检查那些要么不可观察（not observable），要么对系统至关重要（critical）的条件。
    2. BSLS_ASSERT(EXPR)：
      • 特点：默认激活，但可以通过编译标志控制：
        • 如果定义了 -DBDE_BUILD_TARGET_OPT，则禁用（优化模式）。
        • 如果定义了 -DBDE_BUILD_TARGET_SAFE，则启用（安全模式）。
      • 开销：5% 到 20%（性能影响中等）。
      • 用途：用于检查那些成本低但不可忽略的条件。
    3. BSLS_ASSERT_SAFE(EXPR)：
      • 特点：仅在 -DBDE_BUILD_TARGET_SAFE 模式下激活。
      • 开销：大于 20%，可能更高（性能影响较大）。
      • 用途：用于可能开销较高的检查。
  • 总结：这三种宏根据性能开销和检查的必要性分级，允许开发者根据应用需求选择合适的检查级别。

2. 计划（Part II）：提供全局回调机制和三种失败处理器

  • 目标：提供一个全局回调机制，允许自定义失败处理，同时提供三种现成的失败处理器。
  • 回调函数定义：
    typedef void (*Handler)(const char *text, const char *file, int line);
    • 回调函数接受三个参数：失败的断言表达式（text）、文件名（file）和行号（line）。
  • 三种现成的失败处理器：
    1. failAbort：
      • 行为：将错误信息打印到 stderr，然后终止程序（调用 abort()）。
      • 适用场景：适用于需要立即停止程序的严重错误。
    2. failThrow：
      • 行为：将错误信息封装在 std::logic_error 中并抛出异常。
      • 适用场景：适用于希望通过异常机制处理错误的场景。
    3. failSleep（或 failSpin）：
      • 行为：将错误信息打印到 stderr，然后进入循环/休眠状态（等待调试器介入）。
      • 适用场景：适用于调试场景，允许开发者在程序暂停时介入。
  • 改进：根据 C++ 标准委员会 LEWG 的反馈，计划将回调参数整合为一个结构体，简化接口。

3. 示例 1：使用 BSLS_ASSERT

  • 场景：实现一个计算阶乘的函数 factorial。
  • 代码（our_mathutil.h 和 our_mathutil.cpp）：
    // our_mathutil.h
struct MathUtil {
    static double factorial(int n);
    // 返回从 1 到 n 的乘积，若 n 为 0 则返回 1。
    // 要求：0 <= n <= 100，否则行为未定义。
};
// our_mathutil.cpp
#include 
#include 
double MathUtil::factorial(int n) {
    BSLS_ASSERT(0 <= n);  // 检查 n 是否非负
    BSLS_ASSERT(n <= 100);  // 检查 n 是否不超过 100
    // 阶乘实现代码
}
  • 客户端代码（my_client.cpp）：
    #include 
#include 
void someFunction() {
    double z = our::MathUtil::factorial(-5);  // 误用：n < 0
}
  • 运行结果：
    • 编译时需链接 bsls_assert.o。
    • 运行时触发断言失败：
      Assertion failed: 0 <= n, file our_mathutil.cpp, line 365
Abort (core dumped)
  • 分析：使用了 BSLS_ASSERT，默认失败处理器为 failAbort，因此程序在检测到 n < 0 时打印错误并终止。

4. 示例 2：使用 BSLS_ASSERT_SAFE

  • 场景：实现一个正方形类 Square，设置宽度。
  • 代码（our_square.h）：
    #include 
class Square {
    double d_width;
public:
    void setWidth(double width);
    // 要求：width >= 0.0，否则行为未定义。
};
inline void Square::setWidth(double width) {
    BSLS_ASSERT_SAFE(0.0 <= width);  // 检查宽度非负
    d_width = width;
}
  • 客户端代码（my_client.cpp）：
    #include 
#include 
void someFunction() {
    our::Square s;
    s.setWidth(-3.14);  // 误用：width < 0
}
  • 运行结果：
    • 编译时需启用 -DBDE_BUILD_TARGET_SAFE（否则 BSLS_ASSERT_SAFE 不生效）。
    • 运行时触发断言失败：
      Assertion failed: 0 <= width, file our_square.h, line 142
Abort (core dumped)
  • 分析：使用了 BSLS_ASSERT_SAFE，适合内联函数（inline functions），因为这种检查可能开销较高，只有在安全模式下才会触发。

5. 示例 3：使用 BSLS_ASSERT_SAFE

  • 场景：实现一个二维点类 Kpoint。
  • 代码（our_kpoint.h）：
    class Kpoint {
    short int d_x, d_y;
public:
    Kpoint(int x, int y);
    // 要求：-1000 <= x, y <= 1000，否则行为未定义。
};
inline Kpoint::Kpoint(int x, int y) : d_x(x), d_y(y) {
    BSLS_ASSERT_SAFE(-1000 <= x); BSLS_ASSERT_SAFE(x <= 1000);
    BSLS_ASSERT_SAFE(-1000 <= y); BSLS_ASSERT_SAFE(y <= 1000);
}
  • 分析：再次使用 BSLS_ASSERT_SAFE，因为构造函数是内联的，检查条件可能较昂贵，符合指南建议。

6. 示例 4：使用 BSLS_ASSERT

  • 场景：实现一个哈希表类 HashTable，调整大小。
  • 代码（our_hashtable.h 和 our_hashtable.cpp）：
    // our_hashtable.h
class HashTable {
public:
    void resize(double loadFactor);
    // 调整哈希表大小，要求：loadFactor > 0，否则行为未定义。
};
// our_hashtable.cpp
void HashTable::resize(double loadFactor) {
    BSLS_ASSERT(0 < loadFactor);  // 检查 loadFactor 正数
    // 实现代码
}
  • 分析：使用了 BSLS_ASSERT，因为 resize 不是内联函数，且检查成本较低，符合指南建议。

7. 示例 5：使用 BSLS_ASSERT_OPT 和自定义失败处理器

  • 场景：实现一个交易系统类 TradingSystem。
  • 代码（our_tradingsystem.h 和 our_tradingsystem.cpp）：
    // our_tradingsystem.h
class TradingSystem {
public:
    void executeTrade(int scalingFactor);
    // 要求：scalingFactor >= 0 且能被 100 整除，否则行为未定义。
};
// our_tradingsystem.cpp
void TradingSystem::executeTrade(int scalingFactor) {
    BSLS_ASSERT_OPT(0 <= scalingFactor);  // 检查非负
    BSLS_ASSERT_OPT(0 == scalingFactor % 100);  // 检查整除
    // 实现代码
}
  • 客户端代码（自定义 failSpin）：
    int main(int argc, const char *argv[]) {
    bsls_Assert::setFailureHandler(&bsls_Assert::failSpin);  // 设置失败处理器
    return 0;
}
void clientFunction(our::TradingSystem *objectPtr) {
    objectPtr->executeTrade(10022);  // 误用：10022 不能被 100 整除
}
  • 运行结果：
    • 编译时启用 -DBDE_BUILD_TARGET_OPT（但 BSLS_ASSERT_OPT 始终生效）。
    • 运行时触发断言失败：
      (printed message sent to console room, waiting…)
  • 分析：使用了 BSLS_ASSERT_OPT，因为条件对系统至关重要（critical），且开销极低。自定义了失败处理器为 failSpin，程序会暂停并等待调试。

8. 选择 BSLS_ASSERT 的指南*

  • BSLS_ASSERT_SAFE：
    • 用途：检查开销可能较高（>20%）。
    • 建议：用于内联函数（inline functions）。
  • BSLS_ASSERT：
    • 用途：检查成本低但不可忽略（5%-20%）。
    • 建议：用于非内联函数（non-inline functions）。
  • BSLS_ASSERT_OPT：
    • 用途：检查要么不可观察，要么至关重要（<5%）。
    • 建议：用于性能敏感或关键场景。
  • 总结：指南根据性能开销和函数类型（内联/非内联）提供选择建议，平衡安全性和性能。

总体理解

  • bsls_assert 组件通过三种宏（BSLS_ASSERT_OPT、BSLS_ASSERT、BSLS_ASSERT_SAFE）提供分级防御性检查，允许开发者根据性能需求选择合适的检查级别。
  • 失败处理器（failAbort、failThrow、failSleep/failSpin）提供了灵活的错误处理机制，支持终止、抛异常或调试。
  • 示例展示了如何在不同场景（阶乘、几何、正方形、哈希表、交易系统）中使用这些宏，并通过客户端误用演示了断言触发的效果。
  • 设计目标：在保证安全性的同时，尽量减少性能开销，并通过编译标志和自定义处理器提供灵活性，满足不同开发阶段和应用需求。
    这段内容是关于软件开发中防御性检查（Defensive Checks）的进一步扩展，重点介绍了“硬未定义行为”（Hard Undefined Behavior）和“软未定义行为”（Soft Undefined Behavior）的区别，以及如何使用 bsls_assert 组件来处理这些情况。以下是对内容的理解和总结：

1. 硬未定义行为 (Hard UB) 与 软未定义行为 (Soft UB) 的概念

  • 两种未定义行为 (Undefined Behavior, UB)：
    1. 语言未定义行为 (Hard UB)：
      • 由编程语言（如 C++）定义的未定义行为。
      • 后果极端且不可预测，例如内存损坏或程序崩溃，甚至可能导致荒谬的结果（如引用中提到的“你的猫可能怀孕”——Marshall Clow 的幽默表达）。
    2. 库未定义行为 (Soft UB)：
      • 由库的契约（Contract Violation）引起的未定义行为。
      • 目前尚未导致严重后果，但可能演变为 Hard UB。
  • 关系：
    • Soft UB 是相对的概念，取决于开发者的视角。
    • 如果开发者不了解库的实现，Soft UB（契约违反）可能直接导致 Hard UB。
    • 如果开发者是库的实现者或测试驱动程序的开发者，Soft UB 可以保持在可控范围内，不一定升级为 Hard UB。

2. 软未定义行为的相对性

  • 条件：
    • 外部视角（不了解实现）：
      • 契约违反（Soft UB）可能引发 Hard UB，因为缺乏足够信息来预测行为。
    • 内部视角（实现或测试驱动）：
      • 开发者可以利用内部知识，将契约违反限制为 Soft UB，避免升级为 Hard UB。
  • 例子：
    • 如果开发者知道如何处理契约违反（例如通过调试或修复），可以避免更严重的后果。

3. 示例分析：传递 0 是否为未定义行为

  • 示例 1：bsl::strlen 函数
    bsl::size_t bsl::strlen(const char *string)
// 要求：string 必须以 null 终止，否则行为未定义。
{
    BSLS_ASSERT_SAFE(string);  // 断言检查
    const char *p = string;
    while (*p) { ++p; }
    return p - string;
}
    • 分析：如果传入 nullptr（0），BSLS_ASSERT_SAFE 会触发，因为 string 未满足 null 终止条件。这被归类为 Hard UB，因为它可能导致内存访问错误或崩溃。
  • 示例 2：Account::setName 函数
    class Account {
    std::string d_name;
public:
    void setName(const char *name)
    // 要求：name 必须以 null 终止，否则行为未定义。
    {
        BSLS_ASSERT_SAFE(name);  // 断言检查
        d_name = name;
    }
};
    • 分析：同样，传入 nullptr 触发 BSLS_ASSERT_SAFE，被归类为 Hard UB，因为它可能导致无效内存操作。
  • 示例 3：badLibraryFunction vs. goodLibraryFunction
    • 坏的实现：
      void badLibraryFunction(std::string& result, ...)
{
    BSLS_ASSERT_SAFE(&result);  // 太晚了！
    // ...
}
int someClientFunction(std::string *resultId, ...)
{
    // 要求：resultId 必须非空
    badLibraryFunction(*resultId, ...);
}
      • 问题：BSLS_ASSERT_SAFE 检查太晚（在解引用 resultId 之后），如果 resultId 为 nullptr，会导致 Hard UB（解引用空指针）。
    • 好的实现：
      void goodLibraryFunction(std::string *result, ...)
{
    BSLS_ASSERT_SAFE(result);  // 及时检查
    // ...
}
int someClientFunction(std::string *resultId, ...)
{
    // 要求：resultId 必须非空
    goodLibraryFunction(resultId, ...);
}
      • 分析：在解引用前检查 result，如果 resultId 为 nullptr，触发 BSLS_ASSERT_SAFE，保持为 Soft UB（契约违反），避免 Hard UB。
  • 总结：及时的防御性检查可以将潜在的 Hard UB 转换为可控的 Soft UB。

4. 示例 6：使用 failThrow 失败处理器

  • 代码（客户端）：
    int main(int argc, const char *argv[]) {
    bsls_Assert::setFailureHandler(&bsls_Assert::failThrow);  // 设置抛出异常
    // 设置保存内部状态的逻辑
    try {
        // 所有有用工作在这里
    } catch (const std::logic_error& exception) {
        // 保存内部状态并退出
    }
    return 0;
}
  • 分析：
    • 使用 failThrow 处理器，当断言失败时抛出 std::logic_error 异常。
    • 通过 try-catch 块捕获异常，允许在异常发生时保存状态并优雅退出。
    • 提到其他回调类型也可以实现类似目标，表明灵活性。

5. 支持条件编译

  • 对应每个断言级别：
    • BSLS_ASSERT_OPT → BSLS_ASSERT_OPT_IS_ACTIVE
    • BSLS_ASSERT → BSLS_ASSERT_IS_ACTIVE
    • BSLS_ASSERT_SAFE → BSLS_ASSERT_SAFE_IS_ACTIVE
  • 用途：通过条件编译宏，开发者可以根据激活状态动态调整代码行为。

6. 示例 7：使用 BSLS_ASSERT*_IS_ACTIVE

  • 代码（MyDate 类）：
    class MyDate {
    int d_serialDate;  // 有效范围 [1 .. 3652061]
public:
    MyDate();
    // 创建值为 '0001Jan01' 的对象
    #if defined(BSLS_ASSERT_SAFE_IS_ACTIVE)
    ~MyDate();  // 仅在安全模式下定义析构函数
    #endif
};
inline MyDate::MyDate() : d_serialDate(1) { }  // 0001Jan01
#if defined(BSLS_ASSERT_SAFE_IS_ACTIVE)
inline MyDate::~MyDate() {
    BSLS_ASSERT_SAFE(1 <= d_serialDate);             // 检查下限
    BSLS_ASSERT_SAFE(d_serialDate <= 3652061);  // 检查上限
}
#endif
  • 分析：
    • 析构函数和断言检查仅在 BSLS_ASSERT_SAFE_IS_ACTIVE 定义时启用。
    • 这允许在安全模式下验证 d_serialDate 的有效性，优化模式下省略检查以提升性能。
    • 符合条件编译的灵活性需求。

总体理解

  • 硬 vs. 软未定义行为：
    • Hard UB 是语言级别的不可预测错误，Soft UB 是库级别的契约违反，可通过早期检查转化为可控错误。
    • 软未定义行为的严重性取决于开发者对实现的了解程度。
  • 防御性检查的重要性：
    • 通过 BSLS_ASSERT* 宏和及时的检查，可以将 Hard UB 风险降至最低。
    • 示例展示了如何在不同场景下正确使用断言，避免未定义行为升级。
  • 灵活性与性能平衡：
    • 提供多种失败处理器（failThrow 等）和条件编译支持，允许开发者根据需求调整行为和性能开销。
  • 实践指导：
    • 及时的防御性检查（如 goodLibraryFunction）是关键，晚检查（如 badLibraryFunction）可能导致 Hard UB。
    • 条件编译（如 BSLS_ASSERT*_IS_ACTIVE）支持在不同构建目标间切换检查。
      这段内容讨论了在实现防御性检查时，混合模式（Mixed-Mode）构建（即不同断言级别构建）带来的影响，特别是与 ABI 兼容性和 C++ 的**单一定义规则（One-Definition Rule, ODR）**相关的问题。以下是对内容的理解和总结：

1. 混合模式构建的含义

  • 背景：混合模式构建指的是在同一程序中，客户端代码和库代码可能以不同的断言级别（Assertion Level）编译，例如：
    • 客户端可能启用 BSLS_ASSERT_OPT 和 BSLS_ASSERT，而库可能只启用 BSLS_ASSERT_OPT。
    • 这种差异可能出现在内联函数、函数模板等定义中，因为它们可能在头文件中被多次编译。
  • 讨论的问题：
    1. 是否会导致 ABI 不兼容？
    2. 是否会违反 ODR？

2. 影响分析

1. ABI 兼容性
  • 结论：不会导致 ABI 不兼容。
  • 原因：
    • 所有断言级别模式（BSLS_ASSERT_OPT、BSLS_ASSERT、BSLS_ASSERT_SAFE）必须设计为 ABI 兼容。
    • 断言的唯一副作用是调用失败处理器（Failure Handler），不会改变函数的二进制接口（例如函数签名、参数传递方式等）。
2. 违反单一定义规则 (ODR)
  • 结论：会违反 ODR。
  • 原因：
    • 在头文件中使用 bsls_assert（如内联函数或函数模板中）可能导致 ODR 违反。
    • 场景：
      • 内联函数定义（Inline-Function Definitions）：在头文件中定义的内联函数可能在不同编译单元中以不同断言级别编译，导致函数定义不一致。
      • 函数模板定义（Function-Template Definitions）：类似地，函数模板可能因断言级别不同而生成不一致的实例。

3. ODR 违反的详细分析

场景 1：所有函数定义在 .cpp 文件中
  • 表格分析：
    • 客户端构建模式：启用 BSLS_ASSERT_OPT 和 BSLS_ASSERT。
    • 库构建模式：
      • 第一种情况：只启用 BSLS_ASSERT_OPT。
        • 问题：BSLS_ASSERT 在库中未激活，而在客户端中激活，导致行为不一致。
      • 第二种情况：启用 BSLS_ASSERT_OPT 和 BSLS_ASSERT。
        • 问题：BSLS_ASSERT 在库和客户端中都激活，行为一致。
  • 结论：如果函数定义在 .cpp 文件中，ODR 问题不明显，因为每个编译单元有独立的定义。但断言行为的不一致可能导致运行时问题。
场景 2：内联函数定义在 .h 文件中
  • 表格分析：
    • 客户端构建模式：启用 BSLS_ASSERT_OPT 和 BSLS_ASSERT。
    • 库构建模式：启用 BSLS_ASSERT_OPT、BSLS_ASSERT 和 BSLS_ASSERT_SAFE。
      • 问题：BSLS_ASSERT_SAFE 在客户端中可能未激活，而在库中激活，导致内联函数的定义不一致（违反 ODR）。
  • 结论：内联函数在头文件中定义时，不同编译单元可能看到不同的断言级别，导致 ODR 违反。例如：
    • 客户端可能跳过 BSLS_ASSERT_SAFE 的检查，而库期望执行该检查。
场景 3：函数模板定义在 .h 文件中
  • 表格分析：
    • 客户端构建模式：启用 BSLS_ASSERT_OPT 和 BSLS_ASSERT。
    • 库构建模式：只启用 BSLS_ASSERT_OPT。
      • 问题：BSLS_ASSERT 在客户端中激活，但在库中未激活，导致函数模板实例化的定义不一致（违反 ODR）。
  • 结论：函数模板在不同编译单元中实例化时，断言级别的差异会导致生成的代码不一致，进一步违反 ODR。

4. 为什么违反 ODR 在此场景下是“可接受的”？

  • 问题：尽管违反了 ODR，为什么这种行为被认为是“OK”的？
  • 回答：
    1. 语法上（ABI）兼容：
      • 不同断言级别的构建不会改变函数的 ABI（例如函数签名、参数类型等），因此二进制级别上是一致的。
    2. 语义上可替代：
      • 组件级契约（Component-Level Contract）：
        • 如果违反了契约，行为是未定义的（Undefined Behavior），因此不同断言级别的行为差异符合预期（未定义行为允许任何结果）。
      • 库级理解（Library-Level Understanding）：
        • 遵循“看到问题就报告”（See something, Say Something）的原则。断言级别的差异仅影响是否触发失败处理器，而不会改变核心功能。
  • 总结：虽然技术上违反了 ODR，但由于定义在 ABI 级别兼容，且语义上未定义行为允许差异，这种违反在实践中不会导致严重问题。

总体理解

  • 混合模式构建指的是在同一程序中，不同模块以不同断言级别（BSLS_ASSERT_OPT、BSLS_ASSERT、BSLS_ASSERT_SAFE）编译。
  • 影响：
    • ABI 兼容性：断言级别不会影响 ABI，因此混合模式构建在二进制级别是安全的。
    • ODR 违反：在头文件中使用 bsls_assert（如内联函数或函数模板）可能导致 ODR 违反，因为不同编译单元可能看到不一致的定义。
  • ODR 违反的具体场景：
    • .cpp 文件中的定义：影响较小，仅表现为断言行为不一致。
    • 头文件中的内联函数和函数模板：可能因断言级别不同而导致定义不一致，违反 ODR。
  • 为何可接受：
    • 所有定义在 ABI 级别兼容。
    • 语义上，契约违反导致未定义行为，允许行为差异；同时，断言仅触发失败处理器，不会改变核心功能。
  • 实践建议：
    • 尽量避免在头文件中使用高开销的断言（如 BSLS_ASSERT_SAFE），以减少 ODR 违反的风险。
    • 在混合模式构建中，需明确文档说明断言级别的预期行为，确保客户端和库开发者理解潜在差异。
      这段内容强调了在防御性检查中，混合模式构建的复杂性及其对 ODR 的影响，同时提供了为什么这种违反在特定场景下可接受的理由。

1. 示例 8：创建和使用自定义失败处理器

代码：定义自定义失败处理器
  • 文件：main.cpp
  • 代码：
    #include 
#include   // 为了使用 std::printf
static bool globalEnableOurPrintingFlag = true;
static void ourFailureHandler(const char *text, const char *file, int line)
// 打印指定的表达式 'text'、文件名 'file' 和行号 'line' 到 stdout，格式为逗号分隔列表，
// 将空字符串参数替换为空字符串（除非 globalEnableOurPrintingFlag 为 false 禁用打印）；
// 然后无条件终止进程。
{
    if (!text) text = "";  // 防止空指针，替换为 ""
    if (!file) file = "";  // 防止空指针，替换为 ""
    if (globalEnableOurPrintingFlag) {
        std::printf("%s, %s, %d\n", text, file, line);  // 打印信息
    }
    std::abort();  // 终止进程
}
  • 功能：
    • ourFailureHandler 是一个自定义失败处理器，符合 bsls_assert 组件的回调签名：void (*Handler)(const char*, const char*, int)。
    • 检查 text 和 file 是否为 nullptr，如果是则替换为空字符串。
    • 根据全局标志 globalEnableOurPrintingFlag 决定是否打印断言失败信息（格式：text, file, line）。
    • 最后调用 std::abort() 终止程序。
代码：安装和调用自定义失败处理器
  • 代码：
    int main(int argc, const char *argv[])
{
    bsls_Assert::Handler f = &::ourFailureHandler;  // 获取函数指针
    bsls_Assert::setFailureHandler(f);  // 设置自定义失败处理器
    bsls_Assert::invokeHandler("str1", "str2", 3);  // 手动调用处理器
    return 0;
}
  • 编译和运行：
    $ CC -o a.out main.cpp
$ ./a.out
str1, str2, 3
Abort (core dumped)
  • 分析：
    • bsls_Assert::Handler 是一个函数指针类型，用于存储失败处理器的地址。
    • bsls_Assert::setFailureHandler 设置自定义处理器 ourFailureHandler。
    • bsls_Assert::invokeHandler 手动调用处理器，传入测试参数 "str1"、"str2" 和 3。
    • 输出结果符合预期：打印 str1, str2, 3，然后程序因 std::abort() 终止。

2. 回顾计划（Part I）：三种 BSLS_ASSERT 宏*

  • 目标：为库开发者提供三种断言宏，根据性能开销和激活条件分级。
  • 三种宏及默认行为：
    1. BSLS_ASSERT_OPT(EXPR)：
      • 开销：小于 5%（性能影响最小）。
      • 默认行为：始终激活（Always active）。
    2. BSLS_ASSERT(EXPR)：
      • 开销：5% 到 20%（性能影响中等）。
      • 默认行为：
        • 如果定义了 -DBDE_BUILD_TARGET_OPT，则禁用（优化模式）。
        • 如果定义了 -DBDE_BUILD_TARGET_SAFE，则启用（安全模式）。
        • 否则，保持激活。
    3. BSLS_ASSERT_SAFE(EXPR)：
      • 开销：大于 20%，可能更高（性能影响较大）。
      • 默认行为：仅在 -DBDE_BUILD_TARGET_SAFE 模式下激活。
  • 总结：这些宏根据性能开销和构建目标（Build Target）提供灵活的防御性检查选项。

3. 断言级别覆盖（Assertion-Level Overrides）

  • 目标：允许开发者通过构建选项覆盖默认的断言级别（由 BDE_BUILD_TARGET_* 标志决定）。
  • 覆盖选项（在构建命令行中指定，必须选择恰好一个）：
    1. -D BSLS_ASSERT_LEVEL_NONE：
      • 效果：所有断言宏（BSLS_ASSERT_OPT、BSLS_ASSERT、BSLS_ASSERT_SAFE）都不激活。
    2. -D BSLS_ASSERT_LEVEL_ASSERT_OPT：
      • 效果：仅 BSLS_ASSERT_OPT 激活，其他宏（BSLS_ASSERT 和 BSLS_ASSERT_SAFE）不激活。
    3. -D BSLS_ASSERT_LEVEL_ASSERT：
      • 效果：BSLS_ASSERT_OPT 和 BSLS_ASSERT 激活，但 BSLS_ASSERT_SAFE 不激活。
    4. -D BSLS_ASSERT_LEVEL_ASSERT_SAFE：
      • 效果：所有断言宏（BSLS_ASSERT_OPT、BSLS_ASSERT、BSLS_ASSERT_SAFE）都激活。
  • 示例：
    • 在优化构建中启用所有断言宏：
      CC -DBDE_BUILD_TARGET_OPT -DBSLS_ASSERT_LEVEL_ASSERT_SAFE ...
      • 说明：
        • -DBDE_BUILD_TARGET_OPT 通常会禁用 BSLS_ASSERT，但被 -DBSLS_ASSERT_LEVEL_ASSERT_SAFE 覆盖。
        • 结果：所有断言宏（包括 BSLS_ASSERT_SAFE）都激活，即使在优化模式下。

总体理解

  • 自定义失败处理器：
    • 示例 8 展示了如何通过 bsls_assert 组件创建和使用自定义失败处理器 ourFailureHandler。
    • 处理器实现了灵活的错误处理逻辑：根据全局标志决定是否打印错误信息，并始终终止程序。
    • 使用 bsls_Assert::setFailureHandler 安装处理器，bsls_Assert::invokeHandler 测试其行为。
  • 断言级别回顾：
    • 三种 BSLS_ASSERT* 宏（BSLS_ASSERT_OPT、BSLS_ASSERT、BSLS_ASSERT_SAFE）根据性能开销分级，开发者可根据构建目标选择激活哪些宏。
  • 断言级别覆盖：
    • 提供四种覆盖选项（BSLS_ASSERT_LEVEL_*），允许开发者通过构建命令行精确控制断言行为。
    • 覆盖选项可以绕过默认的 BDE_BUILD_TARGET_* 设置，例如在优化构建中强制启用所有断言。
  • 实践意义：
    • 自定义失败处理器增加了错误处理的灵活性，适合特定调试或日志需求。
    • 断言级别覆盖机制允许开发者在不同构建场景（优化、安全、调试）中平衡性能和安全性。
      这段内容继续探讨防御性检查（Defensive Checks）的实现，重点在于二进制不兼容的检查（Binary-Incompatible Defensive Checks）和高开销检查（Disproportionally Expensive Checks），以及如何通过 BDE_BUILD_TARGET_SAFE_2 模式和 bsls_assert 组件处理这些情况。以下是对内容的理解和总结：

1. 二进制不兼容的防御性检查

动机示例：检查迭代器（Checked Iterators）
  • 问题：
    • 解除引用（dereferencing）一个因容器修改而失效的迭代器是未定义行为（Undefined Behavior）。
  • 解决方案：
    • 需要额外的实例数据来实现检查：
      1. 容器：需要维护一个额外的链表（linked list），存储指向迭代器的反向指针（back pointers）。
      2. 迭代器：需要维护一个额外的指针，指向其在链表中的节点。
  • 问题：
    • 这种检查是二进制不兼容的（NOT binary compatible）。
    • 原因：添加额外数据（例如 d_backPointers 链表）会改变容器和迭代器的内存布局（memory layout），从而改变类的 ABI（Application Binary Interface）。这意味着以不同模式编译的代码（启用检查 vs. 不启用检查）无法在二进制级别兼容。

2. 示例 9：使用 BDE_BUILD_TARGET_SAFE_2 处理二进制不兼容检查

  • 代码（my_string.h）：
    class String {
    char            *d_array_p;      // 字符数组
    std::size_t      d_length;       // 字符串长度
    std::size_t      d_capacity;     // 容量
    bslma_Allocator *d_allocator_p;  // 内存分配器
    #if defined(BDE_BUILD_TARGET_SAFE_2)
    bsl::list<iterator *> d_backPointers;  // 反向指针链表
    #endif
    void removeAll() {
        #if defined(BDE_BUILD_TARGET_SAFE_2)
        // 使用 d_backPointers 使所有迭代器失效
        #endif
        d_length = 0;  // 清空字符串
    }
};
  • 分析：
    • 条件编译：通过 #if defined(BDE_BUILD_TARGET_SAFE_2) 控制是否启用二进制不兼容的检查。
    • 反向指针链表：在 BDE_BUILD_TARGET_SAFE_2 模式下，String 类会添加 d_backPointers 成员，用于跟踪所有迭代器。
    • 功能：removeAll 方法在启用 SAFE_2 模式时会使用 d_backPointers 使所有迭代器失效，避免未定义行为。
    • 二进制不兼容：如果 BDE_BUILD_TARGET_SAFE_2 未定义，d_backPointers 不存在，String 类的内存布局不同，导致二进制不兼容。

3. 高开销检查（Disproportionally Expensive Checks）

动机示例：验证排序顺序（Sorted Order）
  • 问题：
    • 在一个排序数组上执行二分查找（Binary Search）的时间复杂度为 O(log n)。
    • 但验证数组是否已排序（isSorted）的时间复杂度为 O(n)，远高于二分查找本身。
  • 扩展问题：
    • 二进制不兼容检查：如前所述，这种检查通常也很昂贵（例如需要遍历所有迭代器，复杂度可能是 O(n)）。
    • 其他高开销检查：即使不涉及二进制不兼容，一些检查在安全模式（Safe Build）下也可能成本过高。
  • 策略：
    • 选择：决定不在“普通”安全模式（BDE_BUILD_TARGET_SAFE）中启用那些最坏情况时间复杂度更高的检查（例如从 O(log n) 增加到 O(n)）。
    • 解决方法：将这类高开销检查放到更高级别的安全模式（如 BDE_BUILD_TARGET_SAFE_2）中。

4. 示例 10：使用 BDE_BUILD_TARGET_SAFE_2 处理高开销检查

代码（my_algorithmutil.h 和 my_algorithmutil.cpp）：
  • 头文件（my_algorithmutil.h）：
    #include 
struct AlgorithmUtil {
    static bool isSorted(const std::vector<int>& a);
    // 检查向量是否已排序
    static bool isMember(const std::vector<int>& a, int v);
    // 检查 v 是否在向量 a 中
    // 要求：a 必须已排序，否则行为未定义
};
  • 实现文件（my_algorithmutil.cpp）：
    bool AlgorithmUtil::isMember(const std::vector<T>& a, int v) {
    #if defined(BDE_BUILD_TARGET_SAFE_2)
    BSLS_ASSERT_SAFE(isSorted(a));  // 检查向量是否已排序
    #endif
    // 实现二分查找逻辑（省略）
}
  • 分析：
    • 高开销检查：isSorted(a) 的时间复杂度为 O(n)，远高于二分查找的 O(log n)。
    • 条件编译：仅在 BDE_BUILD_TARGET_SAFE_2 模式下启用此检查，避免在普通安全模式下影响性能。
    • 契约：isMember 方法要求输入向量已排序，否则行为未定义。通过 BSLS_ASSERT_SAFE 强制检查此条件。
客户端使用：
  • 要求：整个程序必须统一使用（或不使用）-DBDE_BUILD_TARGET_SAFE_2 构建。
    • 原因：SAFE_2 模式可能引入二进制不兼容的更改（如 String 类的 d_backPointers），需要一致性。
  • 默认行为：
    • 在 SAFE_2 模式下，所有断言级别（BSLS_ASSERT_OPT、BSLS_ASSERT、BSLS_ASSERT_SAFE）默认启用。
  • 覆盖断言级别：
    • 可以使用 BSLS_ASSERT_LEVEL_* 覆盖默认断言级别，例如：
      CC -DBDE_BUILD_TARGET_SAFE_2 -DBSLS_ASSERT_LEVEL_ASSERT myalgorithms.cpp ...
      • 效果：在 SAFE_2 模式下，启用高开销检查，但通过 -DBSLS_ASSERT_LEVEL_ASSERT 限制断言级别，仅激活 BSLS_ASSERT_OPT 和 BSLS_ASSERT，禁用 BSLS_ASSERT_SAFE。

5. 构建模式总结（Build-Mode Summary）

  • BDE 构建目标（BDE Build Targets）：
    • DEFAULT：默认模式（未指定其他目标）。
    • -DBDE_BUILD_TARGET_OPT：优化模式。
    • -DBDE_BUILD_TARGET_SAFE：安全模式。
    • -DBDE_BUILD_TARGET_SAFE_2：更高级安全模式（支持二进制不兼容和高开销检查）。
  • BSLS 断言覆盖（BSLS Assertion Overrides）：
    • -DBSLS_ASSERT_LEVEL_NONE：禁用所有断言。
    • -DBSLS_ASSERT_LEVEL_ASSERT_OPT：仅启用 BSLS_ASSERT_OPT。
    • -DBSLS_ASSERT_LEVEL_ASSERT：启用 BSLS_ASSERT_OPT 和 BSLS_ASSERT。
    • -DBSLS_ASSERT_LEVEL_ASSERT_SAFE：启用所有断言（包括 BSLS_ASSERT_SAFE）。
  • 表格（未完全展开，但含义清晰）：
    • 表示不同构建目标和断言覆盖的组合，决定了哪些断言宏会被激活。

总体理解

  • 二进制不兼容检查：
    • 问题：某些防御性检查（如检查迭代器失效）需要额外数据（如反向指针链表），这会改变类的内存布局，导致二进制不兼容。
    • 解决方法：通过 BDE_BUILD_TARGET_SAFE_2 模式控制此类检查，确保启用时整个程序一致构建。
    • 示例：String 类在 SAFE_2 模式下添加 d_backPointers，用于使迭代器失效。
  • 高开销检查：
    • 问题：某些检查（如验证数组是否排序）时间复杂度过高（例如 O(n)），不适合普通安全模式。
    • 解决方法：同样使用 BDE_BUILD_TARGET_SAFE_2 模式，仅在需要时启用此类检查。
    • 示例：AlgorithmUtil::isMember 方法在 SAFE_2 模式下检查输入向量是否已排序。
  • 构建模式：
    • BDE_BUILD_TARGET_SAFE_2 专门用于处理二进制不兼容和高开销的检查，默认启用所有断言级别。
    • 可以通过 BSLS_ASSERT_LEVEL_* 覆盖调整断言级别，平衡安全性和性能。
  • 实践意义：
    • 开发者可以根据需求选择合适的构建模式：
      • 普通安全模式（BDE_BUILD_TARGET_SAFE）用于常规检查。
      • 高级安全模式（BDE_BUILD_TARGET_SAFE_2）用于更彻底但成本更高的检查。
    • 确保构建一致性，避免二进制不兼容问题。
      这段内容是在探讨**“防御性检查（Defensive Checks）”的设计决策**，特别是在 BDE（Bloomberg Development Environment）风格下的库开发中，涉及 bsls_assert 宏、配置策略、编译目标等核心问题。下面是对你列出的问题的逐一解释和理解总结：

问题解析与理解

1. 谁应该决定：检查前置条件花多少 CPU 时间？违反时该怎么办？
  • 答案：应该由**应用程序的拥有者（application owner）**来决定。原因：
    • 他们拥有 main 函数；
    • 对性能、鲁棒性、安全性有最终责任；
    • 可以权衡开发效率与运行成本；
    • 防御性检查的粒度应支持配置。
2. 为什么库开发者不在函数级契约中指定防御性检查内容？
  • 原因：
    • 因为检查是否启用是构建配置（build target）依赖的；
    • bsls_assert 宏是否启用，在不同模式（如 SAFE, OPT, DEBUG）下行为不同；
    • 因此，这些检查并非固定契约的一部分，而是依赖于上下文；
    • 换句话说，不能强制客户端依赖它的存在或行为。
3. 何时使用 BSLS_ASSERT_SAFE vs BSLS_ASSERT vs BSLS_ASSERT_OPT？
  • 用途区分：
    宏 使用时机 检查级别 是否影响性能敏感路径？
    BSLS_ASSERT_SAFE 开发初期、调试期间，检查非关键路径 最严 可能较慢
    BSLS_ASSERT 一般开发时默认启用，适中强度 中等 可接受的成本
    BSLS_ASSERT_OPT 性能敏感代码、发布版本中保留少量关键检查 最轻 通常很快
  • 建议：
    • 尽量用 SAFE 做复杂校验；
    • 用 ASSERT 保证一般契约；
    • 用 OPT 检查基本但致命的错误。
4. 什么是硬（hard）与软（soft）未定义行为？
  • 硬未定义行为（Hard UB）：
    • 行为未定义且系统后果不可预测，例如：
      • 解引用空指针；
      • 越界访问数组；
      • 使用未初始化变量。
    • 可能导致程序崩溃或内存损坏。
  • 软未定义行为（Soft UB）：
    • 技术上未定义，但可以受控处理，例如：
      • 输入无效参数但不立即崩溃；
      • 调用顺序错误；
    • 通常可以通过断言、日志、异常来探测和恢复。
5. bsls_assert 宏为什么会违反 ODR（One Definition Rule）？为什么这可以接受？
  • 两个主要原因：
    1. bsls_assert 的定义在不同构建目标中有不同实现；
    2. 宏展开后，行为在不同编译单元中可能不同（比如一个模块是 SAFE，另一个是 OPT）；
  • 为什么可以接受？
    • bsls_assert 是一个调试辅助工具；
    • 它的语义是在“调试构建”时才真正生效，而不是功能契约的一部分；
    • 在最终发布的 production build 中，这些宏可以被关闭，因此对一致性要求较低；
    • Bloomberg 的构建系统（如 BDE）通过编译目标管理此一致性。
6. 为什么需要 BDE_BUILD_TARGET_SAFE_2？它与 BDE_BUILD_TARGET_SAFE 有何关系与区别？
  • BDE_BUILD_TARGET_SAFE_2 的作用：
    • 是为了解决多个库或组件在链接时包含多个构建目标定义的问题；
    • 特别是不同模块使用 BSLS_ASSERT_SAFE 时避免冲突；
    • 它使得可以安全混合使用 SAFE 与非-SAFE 构建，而不会破坏 ABI。
  • 与 BDE_BUILD_TARGET_SAFE 的关系：
    • SAFE_2 是 SAFE 的扩展或替代，解决其在大规模构建系统中的ODR冲突问题；
    • 使用 SAFE_2 可以使某些宏逻辑在 header 中同时兼容多个目标。

总结：本节重点

核心概念 要点
谁决策防御性检查？ 应用拥有者（因为性能与行为取舍）
为什么不在函数契约中承诺断言行为？ 行为取决于构建配置，非固定的一部分
不同断言宏的使用时机？ 根据调试深度与性能要求灵活使用
硬/软未定义行为区别？ 硬UB不可恢复，软UB可检测处理
为什么允许 ODR 违规？ 宏行为不影响接口语义，是调试用途
SAFE vs SAFE_2 SAFE_2 是为避免 ODR 问题而引入的新机制

“组件级测试驱动（Component-Level Test Driver）” 的介绍，重点说明了它的结构、用途、行为、用户体验，以及调试支持。它是 Bloomberg BDE 测试框架的核心之一。下面是逐页内容的总结与理解：

什么是测试驱动（Test Driver）？

定义

  • 是一个包含 main() 函数的 C++ 文件；
  • 文件名通常形如 component.t.cpp；
  • 用于测试某个组件（component）的行为。

测试驱动的用途

  1. 开发时工具：帮助开发者验证功能正确性；
  2. 回归测试工具：作为自动测试系统的一部分，贯穿组件整个生命周期。

测试驱动包含什么内容？

1. 连续编号的测试用例（Test Cases）

  • 每个测试用例以 case n: 的形式出现；
  • 编号从 1 开始，一直到 n；
  • 每个测试用例包含多个 ASSERT(...) 断言。

2. 测试结构范式

int main(int argc, char *argv[]) {
    int test = argc > 1 ? atoi(argv[1]) : DEFAULT_TEST;
    switch (test) {
      case 1: {
          // Test case 1
          ASSERT(...);
          ...
      } break;
      case 2: {
          // Test case 2
          ...
      } break;
      ...
      default: {
          printf("WARNING: TEST CASE %d NOT FOUND.\n", test);
          return -1;
      }
    }
    return 0;
}

命令行接口/契约（Contract）

格式

testDriver [ testCase# [ addlArgs ... ] ]

行为

  • 默认执行最新（编号最大的）测试用例；
  • 如果指定 testCase#，只执行那个用例；
  • 可额外传入参数影响调试或行为模式。

返回值（Exit Code）

返回值 含义
0 成功，所有断言通过
n > 0 有 n 个断言失败
< 0 测试用例编号无效（not found）

用户体验设计（User Experience）

正常情况

  • 测试应“安静地”成功退出（无输出、状态码为 0）；

错误情况

  • 明确打印断言失败信息，带文件名和行号：
component.t.cpp(42): 2 == sqrt(4) (failed)

Verbose 模式（调试追踪）

启用方式：

  • 如果命令行提供第二个参数（任何值），则开启 verbose 模式：
./component.t.exe 3 verbose

作用：

  • 打印测试驱动的执行流程，方便调试与理解测试逻辑：
    示例输出：
Testing length 0
  without aliasing
  with aliasing
Testing length 1
  ...

额外参数：

  • 传入更多参数，可以进一步增强日志粒度（如打印具体步骤、数据内容等）。

总结：Component-Level Test Driver 要点

方面 要点
核心文件 component.t.cpp，定义 main()
测试结构 switch + 连续编号 case
断言方式 使用 ASSERT(...) 检查行为
命令行接口 testDriver [ testCase# [ args... ] ]
返回值语义 0=成功，n=断言失败数，负值=错误
用户体验 安静成功、有错提示、支持 verbose 输出
用途 初始开发 + 回归测试兼顾

BDE 风格的组件级测试驱动中如何编写一个完整的 Test Case，特别是带有负向测试（Negative Testing）的部分。下面是你提供材料的详细结构解析与总结，帮你 全面理解测试驱动的布局和每个测试用例的编写规范。

测试驱动的布局（Test Driver Layout）

一个典型的测试驱动 (component.t.cpp) 包括以下结构：

1. #include 指令

  • 引入被测试的组件（如 #include ）
  • 引入测试工具，如 #include , #include 等

2. TEST PLAN

  • 明确列出每个测试用例对应测试哪些函数（每个函数至少在一个 case 中测试）
// [ 2] Point(int x, int y) 
// [ 1] void setX(int x) 
// [ 1] int y() const 
// [ 4] void moveBy(int dx, int dy) 
// [ 3] void moveTo(int x, int y)

3. 测试工具支持（Test Apparatus）

  • ASSERT 宏定义
  • 通用辅助函数
  • 设置 verbose 变量支持调试

4. main 函数结构

int main(int argc, char *argv[]) {
    int test = argc > 1 ? atoi(argv[1]) : DEFAULT_TEST;
    bool verbose = argc > 2;
    switch (test) {
        case 1: {
            // TEST CASE 1
        } break;
        case 2: {
            // TEST CASE 2
        } break;
        // ...
        default: {
            cout << "WARNING: TEST CASE " << test << " NOT FOUND.\n";
            return -1;
        }
    }
    return 0;
}

单个测试用例结构（Test Case Layout）

每个 case N 中，按照以下规范书写测试内容：

示例（简化版）：

case 2: {
    //-------------------------------------------------------
    // UNIQUE BIRTHDAY
    //   The value returned for an input of 365 is small.
    //
    // Concerns:
    //: 1 That it can represent the result as a 'double'.
    //: 2 That it returns decreasing values for increasing input.
    //: 6 That the special-case input of 0 returns 1.
    //
    // Plan:
    //   Test explicit values near 0, 365, and INT_MAX.
    //
    // Testing:
    //   double uniqueBirthday(int value);
    //-------------------------------------------------------
    if (verbose) cout << "\nUNIQUE BIRTHDAY\n===============\n";
    ASSERT(1 == uniqueBirthday(0));    // Concern 6
    ASSERT(1 == uniqueBirthday(1));    // Value near zero
    ASSERT(1 >  uniqueBirthday(2));    // Decreasing behavior
    ASSERT(0 <  uniqueBirthday(365));  // Value of interest
    ASSERT(0 == uniqueBirthday(366));  // Boundary test
} break;

说明每部分含义

部分 内容与作用
TITLE 简短的标签，比如 UNIQUE BIRTHDAY，用于 verbose 输出
CONCERNS 明确列出测试这个函数可能出错的点（负向测试关注点）
PLAN 如何用实际代码检测上述 concern，强调方法论而非细节
TESTING 与 test plan 呼应，列出当前测试的是哪个函数
测试代码 使用 ASSERT(...) 检查结果，确保覆盖所有 concern

特别强调：负向测试（Negative Testing）

  • 负向测试不是指 “让程序崩溃”，而是 “测试错误情况是否正确处理”。
  • 比如：
    • 输入非法值是否抛异常或断言失败；
    • 边界条件是否正确处理；
    • 违反 contract 是否触发 BSLS_ASSERT。

总结：BDE 测试驱动的黄金结构

区域 内容
Include 所有依赖头文件
Test Plan 用 [N] 标记函数与测试用例关系
Test Apparatus 定义 ASSERT、通用变量如 verbose
main() 函数 解析测试编号，进入 switch 调用对应测试用例
每个测试用例 有 Title、Concerns、Plan、Testing 注释块，配合断言验证逻辑
返回值 0 成功，正数=断言失败数，负数=未找到测试编号

关于 Negative Testing（负向测试） 的详细解释，特别是在 BDE 测试体系中的应用。以下是你的内容的总结与深入解析，帮助你完全理解这个概念：

什么是 Negative Testing？

定义：

Negative Testing 是一种验证“未在文档中公开声明的防御性检查”是否在预期的 assertion-level build modes 中正确起作用的测试方式。

更通俗地说：

负向测试的目标是验证你写在库内部用来“防止用户滥用”的那些 BSLS_ASSERT/BSLS_ASSERT_SAFE/BSLS_ASSERT_OPT 是否 真的能在你预期的构建模式下触发并起作用。

为什么我们需要负向测试？

这部分你提到了一些“看起来傻”的问题，但其实是很有深度的讨论：

问题 1：为什么要测试 Undefined Behavior？

因为：

  1. 错误检测代码往往是最晚被真正验证的代码（i.e. 很少被触发）。
  2. 但一旦真的需要它时，它是最关键的部分。
    例如：生产环境中的断言失败，往往是阻止数据损坏或系统崩溃的最后一道防线。

问题 2：行为未定义，怎么测试？

你提供的三点回答非常重要：

a. “软”Undefined Behavior ≠ 真正“未定义”
  • Soft Undefined Behavior：比如函数参数是 nullptr 但函数内部没有处理。
  • 在 BDE 中，这类情况我们通常通过 BSLS_ASSERT 等宏 主动插入防御性检查，所以行为是“已知”的（断言失败）。
b. 测试驱动是白盒的
  • 测试驱动拥有白盒知识，知道哪些地方插入了断言。
  • 所以我们可以刻意调用那些会违反 precondition 的情况，以确认断言是否会触发。
c. 防御性检查能在问题变成真正“致命”之前拦截
  • 例如：你传了非法的指针，但断言会在解引用前拦截，避免崩溃或数据损坏。

总结：Negative Testing 的意义与应用

项目 内容
目的 确保防御性断言（如 BSLS_ASSERT）能在 debug/safe 构建中被正确触发
测试什么 违反 precondition 的调用是否触发断言（例如传非法参数）
为什么重要 错误检测机制往往在运行时才被用到，必须在开发阶段被验证
可以测试吗？ 可以！因为我们知道断言具体位置（白盒）
重点 Soft undefined behavior 是测试的重点对象

示例：什么样的情况需要负向测试？

void setSize(int size) {
    BSLS_ASSERT(size > 0);  // Defensive check
    d_size = size;
}

测试代码：

if (veryVerbose) cout << "Testing setSize precondition failure\n";
// Negative test - deliberately violate precondition
ASSERT_SAFE_FAIL(obj.setSize(0));     // This should trigger BSLS_ASSERT_SAFE
ASSERT_SAFE_PASS(obj.setSize(1));     // Valid case

总结语

Negative Testing 是对库质量的关键保障机制。它不是“非正常测试”，而是有策略、有目的地 验证程序在遭遇非法输入时是否以可预期的方式失败（fail-fast）。这在金融系统、航空、医疗等高可靠性系统中至关重要。

Negative Testing（负向测试） 成功所需的条件，以及如何借助 bsls_asserttest 组件来实现它。以下是对你提供内容的全面整理和理解，方便你更系统地掌握这个主题。

Negative Testing 成功的条件（Requirements）

1. 可观察的 contract 违规

必须能够调用一个超出函数契约（contract）的用法，并能观察到这个误用被捕获了。

  • 重点：观察到断言被触发。
  • 前提：测试中必须避免真正的“硬” undefined behavior（比如：解引用空指针、数组越界写入等可能导致 crash 或数据损坏的操作）。

2. 实现必须简单易用

Negative testing 必须非常容易在任何测试环境（尤其是我们自己的）中实现。

  • 测试者不应该花很多时间在“本来就不应该被调用”的代码上。
  • 所以需要有标准的机制、宏、工具来辅助。

3. 运行必须高效、集中

Negative tests 必须容易并高效地运行。

  • 不能每个负向测试都要一个独立进程（太繁琐）。
  • 所有负向测试可以在一个测试驱动中集中运行，并捕获预期的断言失败。

附加注意事项（Additional Concerns）

1. 错误应由当前组件本身捕获

Contract violation 必须被当前测试的组件所捕获。

  • 不要因为底层调用了其他组件的断言而误以为是本组件捕获了错误。
  • 要测试的是你写的 defensive check 是否起效。

2. 仅在 defensive check 被激活的构建模式下调用违规行为

不要在防御性断言不启用的构建模式下执行负向测试。

  • 否则会真正触发 undefined behavior。
  • 例如只在 BSLS_ASSERT_SAFE_IS_ACTIVE 时运行某些断言测试。

如何实现 Negative Testing？（Using bsls_asserttest）

1. 自定义断言失败处理机制

创建一个专门用于测试的断言失败处理器（test handler），它抛出一个特制的异常，该异常记录断言触发的详细信息：

异常内容包含：
字段 描述
a. 组件文件名
b. 源码行号
c. 断言失败的表达式
d. 断言的级别（如 SAFE / ASSERT / OPT）
这是为了让测试代码能准确判断是不是预期的断言在预期位置触发。

2. 使用辅助宏和工具函数

bsls_asserttest 提供了一套宏和工具函数（如 BSLS_ASSERTTEST_ASSERT_SAFE_FAIL）用来简化负向测试。

示例：
#include 
#include 
void setSize(int size) {
    BSLS_ASSERT_SAFE(size > 0);
    // ...
}
int main() {
    using namespace bsls;
    // 设置测试断言处理器
    AssertTest::setFailureHandler(AssertTest::failTestDriver);
    // 开始负向测试
    if (BSLS_ASSERT_SAFE_IS_ACTIVE) {
        ASSERT(AssertTest::tryFailure(BSLS_ASSERTTEST_ASSERT_SAFE_FAIL(setSize(0))));
        ASSERT(AssertTest::tryPass  (BSLS_ASSERTTEST_ASSERT_SAFE_PASS(setSize(5))));
    }
    return 0;
}

总结：Negative Testing 要点总览

关键点 解释
测试目的 验证内部断言机制能如预期那样“在需要时阻止错误调用”
测试方式 使用白盒方式，故意违反 precondition 并确认断言被触发
工具支持 bsls_asserttest 提供了标准宏、辅助类、失败处理机制
注意事项 不要在断言未激活的构建模式中做违规测试，防止硬崩溃
要求 实现要简单、运行要集中高效、异常要精确捕获信息
这段内容讨论了负向测试（Negative Testing），即通过 bsls_asserttest 组件测试函数在违反其契约（narrow contract）时的行为，验证防御性检查是否按预期触发。以下是对内容的理解和总结：

1. 负向测试计划（Plan for Each Test Driver）

  • 目标：为每个测试驱动程序（Test Driver）设计负向测试，以验证函数在超出定义行为边界时的表现。
  • 步骤：
    1. 前提：
      • 假设测试驱动程序中已定义标准的 ASSERT 测试宏，用于处理负向测试中的错误。
    2. 针对具有窄契约（narrow contract）的函数，在每个测试用例（test case）末尾执行以下操作：
      1. 安装自定义失败处理器：
        • 使用 bsls_Assert::setFailureHandler 设置 bsls_AssertTest::failTestDriver 作为失败处理器。
      2. 调用函数，测试边界条件：
        • 在定义行为的边界两侧（即合法和非法输入）调用函数，例如超出契约范围的输入。
      3. 观察断言触发情况：
        • 检查断言是否按当前构建模式（build mode）的预期触发（或不触发）。
      4. 无需关注预期结果：
        • 预期结果已在之前的测试中覆盖，这里仅关注断言行为。

2. 示例：测试 factorial(n) 函数

  • 函数契约：
    • factorial(n) 要求 0 <= n <= 100，否则行为未定义。
  • 测试代码（添加到测试用例末尾）：
    bsls_Assert::setFailureHandler(&bsls_AssertTest::failTestDriver);
BSLS_ASSERTTEST_ASSERT_FAIL(factorial(-1));   // 超出下界，期望失败
BSLS_ASSERTTEST_ASSERT_PASS(factorial(0));    // 边界值，期望通过
BSLS_ASSERTTEST_ASSERT_PASS(factorial(100));  // 边界值，期望通过
BSLS_ASSERTTEST_ASSERT_FAIL(factorial(101));  // 超出上界，期望失败
  • 分析：
    • 安装处理器：bsls_AssertTest::failTestDriver 是一个专门用于测试的失败处理器，会抛出 bsls_AssertTestException 异常，而不是终止程序。
    • 测试用例：
      • factorial(-1)：n < 0，违反契约，期望断言触发（BSLS_ASSERTTEST_ASSERT_FAIL）。
      • factorial(0)：n = 0，符合契约，期望断言不触发（BSLS_ASSERTTEST_ASSERT_PASS）。
      • factorial(100)：n = 100，符合契约，期望断言不触发（BSLS_ASSERTTEST_ASSERT_PASS）。
      • factorial(101)：n > 100，违反契约，期望断言触发（BSLS_ASSERTTEST_ASSERT_FAIL）。

3. 宏展开：BSLS_ASSERTTEST_ASSERT_FAIL 和 BSLS_ASSERTTEST_ASSERT_PASS

单个宏展开（以 BSLS_ASSERTTEST_ASSERT_FAIL(factorial(-1)) 为例）：
  • 展开后代码：
    #if BSLS_ASSERT_IS_ACTIVE
try {
    factorial(-1);
    ASSERT(false);  // 如果未触发断言，则测试失败
} catch(const bsls_AssertTestException& e) {
    ASSERT(0 == strcmp("our_mathutil.cpp", e.filename()));  // 验证断言来源文件
}
#endif
  • 逻辑：
    • 条件编译：仅在 BSLS_ASSERT_IS_ACTIVE 启用时执行（即 BSLS_ASSERT 宏处于激活状态）。
    • 尝试调用：调用 factorial(-1)，期望触发断言。
    • 异常捕获：
      • 如果断言触发，bsls_AssertTest::failTestDriver 抛出 bsls_AssertTestException。
      • 捕获异常并验证断言来源文件（our_mathutil.cpp）。
    • 失败情况：
      • 如果未触发断言（即 factorial(-1) 没有失败），执行到 ASSERT(false)，测试失败。
完整测试代码展开：
  • 展开后代码：
    bsls_Assert::setFailureHandler(&bsls_AssertTest::failTestDriver);
#if BSLS_ASSERT_IS_ACTIVE
try {
    factorial(-1);
    ASSERT(false);  // 应触发断言，不应到达这里
} catch(const bsls_AssertTestException& e) {
    ASSERT(0 == strcmp("our_mathutil.cpp", e.filename()));
}
#endif
factorial(0);   // 期望通过，无需额外检查
factorial(100); // 期望通过，无需额外检查
#if BSLS_ASSERT_IS_ACTIVE
try {
    factorial(101);
    ASSERT(false);  // 应触发断言，不应到达这里
} catch(const bsls_AssertTestException& e) {
    ASSERT(0 == strcmp("our_mathutil.cpp", e.filename()));
}
#endif
  • 逻辑：
    • 失败测试（BSLS_ASSERTTEST_ASSERT_FAIL）：
      • factorial(-1) 和 factorial(101) 违反契约，期望触发断言。
      • 使用 try-catch 捕获 bsls_AssertTestException，验证断言是否按预期触发。
    • 通过测试（BSLS_ASSERTTEST_ASSERT_PASS）：
      • factorial(0) 和 factorial(100) 符合契约，调用时不期望触发断言。
      • 直接调用，不包裹在 try-catch 中（未明确展开，但逻辑上不需要检查异常）。

4. 实现经验观察（Implementation Experience Observation）

  • 虽然内容未完整展开，但可以推测：
    • 观察：负向测试通过 bsls_asserttest 组件验证了断言的正确性，确保函数在违反契约时按预期触发断言。
    • 意义：这种方法有助于发现防御性检查的遗漏或错误，确保代码的鲁棒性。

总体理解

  • 负向测试：
    • 针对具有窄契约的函数，测试其在违反契约时的行为，确保防御性检查（如 BSLS_ASSERT）按预期工作。
    • 测试边界条件（例如 factorial 的 n < 0 和 n > 100），验证断言触发。
  • 测试流程：
    • 使用 bsls_AssertTest::failTestDriver 处理器，捕获断言失败的异常。
    • 使用 BSLS_ASSERTTEST_ASSERT_FAIL 和 BSLS_ASSERTTEST_ASSERT_PASS 宏，分别验证断言触发和不触发的情况。
  • 宏展开：
    • BSLS_ASSERTTEST_ASSERT_FAIL：期望断言触发，捕获异常并验证。
    • BSLS_ASSERTTEST_ASSERT_PASS：期望断言不触发，直接调用函数。
  • 实践意义：
    • 负向测试是单元测试的重要部分，确保函数在非法输入下不会默默失败。
    • bsls_asserttest 组件提供了专门的工具（宏和失败处理器），简化了负向测试的实现。
    • 通过条件编译（BSLS_ASSERT_IS_ACTIVE），测试可以适应不同的构建模式。
      这段内容继续探讨负向测试（Negative Testing），使用 bsls_asserttest 组件测试防御性检查的行为，重点在于实现经验、特殊场景（如构造函数测试）以及 C++ 标准中 noexcept 的引入对防御性编程和负向测试的影响。以下是对内容的理解和总结：

1. 实现经验观察（Implementation Experience Observation）

  • 问题：
    • 如果“正向测试”（positive test）改变了对象状态（例如分配内存），需要在所有构建模式（build modes）下运行，否则清理代码会变得过于复杂。
  • 原因：
    • 状态变化：正向测试可能会修改对象状态（如 vector 的内存分配），而负向测试可能依赖这些状态。
    • 构建模式差异：
      • BSLS_ASSERTTEST_ASSERT_SAFE_FAIL 仅在“安全模式”（Safe Mode，例如 BDE_BUILD_TARGET_SAFE）下启用。
      • BSLS_ASSERTTEST_ASSERT_SAFE_PASS 则始终运行（无论构建模式）。
    • 如果正向测试（如 push_back）仅在某些模式下运行，负向测试可能面临不一致的状态，导致清理逻辑复杂。
示例：测试 bsl::vector
  • 代码：
    bsl::vector<int> v;
bsls_Assert::setFailureHandler(&bsls_AssertTest::failTestDriver);
BSLS_ASSERTTEST_ASSERT_SAFE_FAIL(v[0]);  // 空向量，访问 v[0] 应失败
v.push_back(9);                          // 添加元素，改变状态
BSLS_ASSERTTEST_ASSERT_SAFE_PASS(v[0]);  // 现在 v[0] 合法，期望通过
BSLS_ASSERTTEST_ASSERT_SAFE_FAIL(v[1]);  // v[1] 越界，期望失败
v.push_back(42);                         // 再次改变状态
BSLS_ASSERTTEST_ASSERT_SAFE_PASS(v[0]);  // v[0] 合法，期望通过
BSLS_ASSERTTEST_ASSERT_SAFE_PASS(v[1]);  // v[1] 合法，期望通过
BSLS_ASSERTTEST_ASSERT_SAFE_FAIL(v[2]);  // v[2] 越界，期望失败
v.pop_back();                            // 移除元素，改变状态
BSLS_ASSERTTEST_ASSERT_SAFE_PASS(v[0]);  // v[0] 仍合法，期望通过
BSLS_ASSERTTEST_ASSERT_SAFE_FAIL(v[1]);  // v[1] 越界，期望失败
  • 分析：
    • 状态依赖：v.push_back 和 v.pop_back 修改了向量状态，影响后续测试。
    • 正向测试始终运行：BSLS_ASSERTTEST_ASSERT_SAFE_PASS 总是执行，确保状态变更（如 push_back）在所有模式下发生。
    • 负向测试依赖模式：BSLS_ASSERTTEST_ASSERT_SAFE_FAIL 仅在 SAFE 模式下运行，避免在禁用 BSLS_ASSERT_SAFE 的模式下测试不一致。
    • 清理问题：如果正向测试（如 push_back）不运行，可能会导致内存泄漏或状态不一致，清理代码需要额外处理不同模式。

2. 构造函数的独特问题

  • 问题：
    1. 初始化列表可能先触发断言：
      • 构造函数的初始化列表（Initializer List）可能在主体代码之前执行断言。
      • 问题 1：虽然能正确检测误用，但可能返回错误的源文件名。
      • 问题 2：如果初始化列表中的代码（如 MyDateImpUtil::toSerial）抛出测试异常（bsls_AssertTestException），会导致测试失败。
    • 示例：
      MyDate::MyDate(int y, int m, int d)
    : d_serialDate(MyDateImpUtil::toSerial(y, m, d))  // 初始化列表可能触发断言
{
    BSLS_ASSERT(MyDate::isValid(y, m, d));  // 太晚了！
}
      • 问题：
        • MyDateImpUtil::toSerial 可能在初始化列表中触发断言，导致 BSLS_ASSERT 尚未执行。
        • 如果 toSerial 抛出测试异常，异常信息中的文件名可能不是预期的（例如不是 MyDate 所在的源文件）。
        • 更严重的是，契约违反可能导致未定义行为（Undefined Behavior），甚至在断言触发之前。
  • 解决方案：
    • 引入 _RAW 宏：
      • 提供特殊版本的宏（如 BSLS_ASSERTTEST_ASSERT_FAIL_RAW 和 BSLS_ASSERTTEST_ASSERT_PASS_RAW），仅放宽文件名检查。
    • 测试代码：
      bsls_Assert::setFailureHandler(&bsls_AssertTest::failTest);
BSLS_ASSERTTEST_ASSERT_PASS_RAW(MyDate(2000, 7, 15));  // 合法日期，期望通过
BSLS_ASSERTTEST_ASSERT_FAIL_RAW(MyDate(0, 7, 15));     // 年份无效，期望失败
BSLS_ASSERTTEST_ASSERT_FAIL_RAW(MyDate(10000, 7, 15)); // 年份无效，期望失败
BSLS_ASSERTTEST_ASSERT_FAIL_RAW(MyDate(2000, 0, 15));  // 月份无效，期望失败
BSLS_ASSERTTEST_ASSERT_FAIL_RAW(MyDate(2000, 13, 15)); // 月份无效，期望失败
BSLS_ASSERTTEST_ASSERT_FAIL_RAW(MyDate(2000, 7, 0));   // 日期无效，期望失败
BSLS_ASSERTTEST_ASSERT_FAIL_RAW(MyDate(2000, 7, 32));  // 日期无效，期望失败
    • 分析：
      • _RAW 宏：放宽文件名检查，允许初始化列表中的断言触发时不验证文件名。
      • 测试用例：
        • 合法输入：MyDate(2000, 7, 15) 应通过。
        • 非法输入：年份（0 或 10000）、月份（0 或 13）、日期（0 或 32）超出范围，期望触发断言。

3. 负向测试 SAFE_2 模式下的检查

  • 问题：
    • 某些防御性检查仅在 SAFE_2 模式（BDE_BUILD_TARGET_SAFE_2）下启用，测试代码需要匹配这种条件。
  • 解决方案：
    • 使用条件编译包裹负向测试：
      #if defined(BSLS_BUILD_TARGET_SAFE_2)
BSLS_ASSERTTEST_ASSERT_SAFE_FAIL(…);
BSLS_ASSERTTEST_ASSERT_SAFE_PASS(…);
#endif
    • 原因：
      • 确保仅在 SAFE_2 模式下测试对应的防御性检查，避免在其他模式下运行不一致的测试。

4. 负向测试相关问题解答

  • 什么是负向测试，为什么重要？
    • 定义：负向测试验证函数在违反契约时的行为，确保防御性检查（如断言）按预期触发。
    • 重要性：防止未定义行为被忽视，提升代码健壮性和可靠性。
  • 为什么可以可靠测试库的未定义行为？
    • 使用 bsls_asserttest 组件，捕获断言触发的异常（bsls_AssertTestException），从而安全地测试未定义行为。
  • 为什么断言级别构建模式对负向测试重要？
    • 不同构建模式（例如 SAFE、SAFE_2）启用不同级别的断言，负向测试需要匹配当前模式，确保测试一致性。
  • 为什么总是执行正向测试，但不总是执行负向测试？
    • 正向测试可能改变状态（如分配内存），需要在所有模式下运行以保持一致性；负向测试（如 BSLS_ASSERTTEST_ASSERT_SAFE_FAIL）依赖构建模式，仅在断言启用时运行。
  • 为什么负向测试阶段不关心预期结果？
    • 负向测试关注防御性检查的触发，而非函数返回值（预期结果已在正向测试中验证）。
  • 构造函数为何有独特问题，如何处理？
    • 问题：初始化列表可能先触发断言，导致文件名错误或未定义行为。
    • 解决：使用 _RAW 宏放宽文件名检查，允许测试继续验证断言行为。
  • 如何负向测试 SAFE_2 模式下的检查？
    • 使用条件编译（#if defined(BSLS_BUILD_TARGET_SAFE_2)）包裹测试代码，确保仅在对应模式下运行。

5. C++ 标准中的 noexcept（2011 年引入）

背景：
  • 引入时间：2011 年 3 月，C++ 标准委员会引入 noexcept 异常规范。
  • 用途：
    1. 支持移动语义：移动构造函数和移动赋值操作通常具有宽契约（wide contracts），使用 noexcept 确保不抛出异常。
    2. 优化：为函数添加 noexcept 可带来速度和空间优化（例如编译器可省略异常处理代码）。
    3. 行为：如果 noexcept 函数尝试抛出异常，程序会直接终止（调用 std::terminate）。
对防御性编程和负向测试的影响：
  • 问题：
    • 标准委员会倾向于广泛应用 noexcept，包括窄契约函数（如 vector::front() 和 vector::operator[]）。
    • 窄契约函数：如果违反契约（例如访问空 vector 的 front()），防御性检查可能抛出异常（如 bsls_AssertTestException），但 noexcept 会导致程序终止，无法捕获异常。
  • 作者的建议（2011 年 3 月 21 日）：
    1. 仅用于移动语义：noexcept 应仅用于移动构造函数和移动赋值（语义需求）。
    2. 宽契约且永不抛出：noexcept 可用于宽契约函数，且保证不抛出异常（75% 共识）。
    3. 任何永不抛出的操作：noexcept 可用于任何契约中永不抛出的操作（作者强烈反对：“Over my dead body!”）。
  • 结果：
    • 委员会在 2011 年 3 月 25 日（马德里会议）批准了新标准，提前一天完成。
    • 按上述准则，将 noexcept 应用于整个 C++ 标准库的每个函数。
相关性：
  • 防御性编程：
    • noexcept 与窄契约函数冲突：防御性检查可能抛出异常（如测试异常），但 noexcept 会终止程序，破坏测试流程。
    • 建议：避免在窄契约函数上使用 noexcept，以保留防御性检查的灵活性。
  • 负向测试：
    • 负向测试依赖抛出异常（如 bsls_AssertTestException）来验证断言行为。
    • 如果函数标记为 noexcept，测试无法捕获异常，导致测试失败或程序终止。

6. 总结（Conclusion）

1. 物理设计回顾：
  • 组件：软件设计的基本单位，包括 .h、.cpp 和测试驱动文件（.t.cpp）。
  • 关系：类之间的逻辑关系对应组件间的物理依赖。
  • 层级：无环物理设计通过层级编号（level numbers）描述。
2. 接口与契约：
  • 接口：语法层面；契约：语义层面，定义前置/后置条件。
  • 未定义行为：违反前置条件导致未定义行为，行为不可预测。
  • 测试：测试驱动程序验证必要行为（Essential Behavior）；析构函数中的断言验证不变式。
3. 好的契约：
  • 防御性编程：强调不容错（fault intolerance）。
  • 窄契约：带来未定义行为，但好处包括：
    • 降低开发/测试成本。
    • 提升性能，减小代码体积。
    • 实现实用有效的防御性编程。
    • 允许按需添加有用行为。
4. 实现防御性检查（bsls_assert 组件）：
  • 协作：bsls_assert 组件允许应用和库开发者协作，平衡检查时间和处理方式。
  • 优势：享受防御性编程的好处，避免传统缺点。
5. 负向测试（bsls_asserttest 组件）：
  • 重要性：测试防御性检查是确保正确性的关键。
  • 工具：bsls_asserttest 使负向测试实用、高效。
  • 注意：仅在断言激活时测试防御性检查。
  • 构造函数：测试构造函数具有独特问题（初始化列表问题），通过 _RAW 宏解决。

总体理解

  • 负向测试实践：
    • 负向测试验证防御性检查，确保函数在违反契约时按预期触发断言。
    • 正向测试需始终运行以保持状态一致性，负向测试则依赖构建模式。
    • 构造函数测试需特殊处理，使用 _RAW 宏放宽文件名检查。
    • SAFE_2 模式检查通过条件编译测试，确保一致性。
  • C++ 标准中的 noexcept：
    • noexcept 的引入优化了移动语义和性能，但与窄契约函数冲突，可能影响防御性检查和负向测试。
    • 作者建议限制 noexcept 使用，避免在窄契约函数上应用。
  • 总结：
    • 防御性编程和负向测试是确保代码健壮性的关键。
    • bsls_assert 和 bsls_asserttest 组件提供了强大工具，支持灵活的检查和测试。
    • C++ 标准的演进（如 noexcept）需要与防御性编程策略协调，以避免冲突。

你可能感兴趣的:(CppCon,学习,c++,开发语言)

  • x86-64汇编语言训练程序与实战 十除以十等于一
    本文还有配套的精品资源，点击获取简介：汇编语言是一种低级语言，与机器代码紧密相关，特别适用于编写系统级代码及性能要求高的应用。nasm编译器是针对x86和x86-64架构的汇编语言编译器，支持多种语法风格和指令集。项目Euler提供数学和计算机科学问题，鼓励编程技巧应用，前100个问题的答案可共享。x86-64架构扩展了寄存器数量并引入新指令，提升了数据处理效率。学习汇编语言能够深入理解计算机底层
  • 三菱PLC全套学习资料及应用手册 good2know
    本文还有配套的精品资源，点击获取简介：三菱PLC作为工业自动化领域的核心设备，其系列产品的学习和应用需要全面深入的知识。本次资料包为学习者提供从基础到进阶的全方位学习资源，包括各种型号PLC的操作手册、编程指南、软件操作教程以及实际案例分析，旨在帮助用户系统掌握PLC的编程语言、指令系统及在各类工业应用中的实施。1.三菱PLC基础知识入门1.1PLC的基本概念可编程逻辑控制器（PLC）是工业自动化
  • 日更006 终极训练营day3 懒cici
    人生创业课（2）今天的主题：学习方法一：遇到有用的书，反复读，然后结合自身实际，列践行清单，不要再写读书笔记思考这本书与我有什么关系，我在哪些地方能用到，之后我该怎么用方法二：读完书没映像怎么办?训练你的大脑，方法：每读完一遍书，立马合上书，做一场分享，几分钟都行对自己的学习要求太低，要逼自己方法三：学习深度不够怎么办？找到细分领域的榜样，把他们的文章、书籍、产品都体验一遍，成为他们的超级用户，向
  • day15｜前端框架学习和算法 universe_01 前端算法笔记
    T22括号生成先把所有情况都画出来，然后（在满足什么情况下）把不符合条件的删除。T78子集要画树状图，把思路清晰。可以用暴力法、回溯法和DFS做这个题DFS深度搜索：每个边都走完，再回溯应用：二叉树搜索，图搜索回溯算法=DFS+剪枝T200岛屿数量（非常经典BFS宽度把树状转化成队列形式，lambda匿名函数“一次性的小函数，没有名字”setup语法糖：让代码更简洁好写的语法ref创建：基本类型的
  • 《极简思维》第三部分 小洋苏兮
    整理你的人际关系如何改善人际关系？摘录：因为人际关系问题是人们生活中不快乐的主要原因。感想：感觉这个说的挺对，之前我总是埋头学习，不管舍友不管自己的合作伙伴的一些事情，但实际上，这学期关注了之后好多了摘录：“亲密关系与社交会让你健康而快乐。这是基础。太过于关注成就或不太关心人际关系的人都不怎么快乐。基本上来说，人类就是建立在人脉关系上的。”感想：但是如果有时想的太多就不太好，要以一个开放的心态跟别
  • 你要记住，最重要的是:随时做好准备，为了你可能成为更好的自己，放弃现在的自己。 霖霖z
    打卡人:周云日期:2018年11月09日【日精进打卡第180天】【知～学习】《六项精进》0遍共214遍《通篇》1遍共106遍《大学》2遍共347遍《坚强工作，温柔生活》ok《不抱怨的世界》104-108页《经典名句》你要记住，最重要的是:随时做好准备，为了你可能成为更好的自己，放弃现在的自己。【行～实践】一、修身：（对自己个人）1、坚持打卡二、齐家：（对家庭和家人）打扫卫生，接送孩子，洗衣做饭，陪
  • C++ 计数排序、归并排序、快速排序 每天搬一点点砖 c++数据结构算法
    计数排序：是一种基于哈希的排序算法。他的基本思想是通过统计每个元素的出现次数，然后根据统计结果将元素依次放入排序后的序列中。这种排序算法适用于范围较小的情况，例如整数范围在0到k之间计数排序步骤：1初始化一个长度为最大元素值加1的计数数组，所有元素初始化为02遍历原始数组，将每个元素值作为索引，在计数数组中对应位置加13将数组清空4遍历计数器数组，按照数组中的元素个数放回到元数组中计数排序的优点和
  • 贫穷家庭的孩子考上985以后会怎样？ Mellisa蜜思言
    我出生在一个贫穷的农村家庭，据我妈说，我出生的时候才4斤多，而她生完我以后月子里就瘦到70斤。家里一直很穷，父母都是在菜市场卖菜的，家里还有几亩地种庄稼的。我很小开始就要去帮忙，暑假的生活就是帮忙去卖菜和割稻谷，那时候自己对于割稻谷这种事情有着莫名的恐惧，生怕自己长大以后还是每年都要过着割稻谷这种日子。父母因为忙于生计无暇顾及我的学习，幸好我因为看到他们这样子的生活，内心里有深深的恐惧感，驱使着我
  • 2019-06-05 第十七把巴鲁克
    今天去实验田里实习，见到了福寿螺真的可怕且牛皮，六级也快来了，说实话还是害怕。我昨天考了环工原理，真的太难了，太烦了，理工科真的难，烦。实验报告还是没写，要抓紧速度抓紧时间，还是应该学会努力学习，远离一些不上进的事物。
  • 【C++算法】76.优先级队列_前 K 个高频单词 流星白龙 优选算法C++c++算法开发语言
    文章目录题目链接：题目描述：解法C++算法代码：题目链接：692.前K个高频单词题目描述：解法利用堆来解决TopK问题预处理一下原始的字符串数组，用一个哈希表统计一下每一个单词出现的频次。创建一个大小为k的堆频次：小根堆字典序（频次相同的时候）：大根堆循环让元素依次进堆判断提取结果C++算法代码：classSolution{//定义类型别名，PSI表示对typedefpairPSI;//自定义比较
  • 为什么焦虑、抑郁、自残的青少年越来越多？ 精神健康
    很多家长觉得没缺孩子吃的穿的，他们有安稳的生活，他们有什么可焦虑、抑郁的，但现在的孩子，学习压力越来越大，每天休息的时间越来越少，出现焦虑抑郁是很正常的。从发展的角度看，青少年时期，人的身体、情绪，智力、人格都急剧发展，正从未成熟走向成熟，情绪起伏不定，易冲动，再者，由于缺乏生活经验，以及来自于家长、学校、社会的各种要求和压力，从而不知所措，心中的焦虑、恐惧、彷徨得不到及时的排解，从而导致心理上的
  • 读书打卡《别想太多啦》 chenchen_68ed
    第一，世间之事，不去尝试永远不知道其中的奥秘，在尝试中有失败是必然的。如果担心失败，那什么都学不会。第二，经历的失败越多，越会对失败者抱有宽容的态度，“原来如此，我也经历过类似的失败啦，那只是暂时的”。经历越多失败的长者，越能包容别人，这也就是所谓的“越年长越宽容”。成熟的人，就是在众多失败经历中不断学习，并接纳别人的失败。对于他人的小小过失不吹毛求疵，自己的心态会更加平和。在不断失败中学习，让自
  • 2023-01-26 胡喜平
    我觉得《可见的学习》一书确实从底层逻辑说清楚了，教学的本质。可是太多术语和概念，一时间难以消化啊。而且知道和懂得有距离，运用就更不行了，需要高手和专家的指导。我需要多听听新课标的讲座了，来反复印证。读论文也有了一点点灵感，明天修改我的论文。
  • 平静得接受自己的笨拙 20190118 晨间日记 吴伯符
    图片发自App最近做了一个关于微习惯的分享，这里有八个字：微量开始，超额完成。这里的言下之意其实是要你在一开始的时候，平静地接受自己的笨拙。接受自己的笨拙，理解自己的笨拙，放慢速度尝试，观察哪里可以改进，再反复练习，观察自己哪里可以再进一步改进，再反复…这是学习一切技能的必须的过程。这里的两个关键点是：1.尽快的开始这个过程，这就能够用到微习惯的微量开始。2.尽快的度过这个过程，这就需要用到超额完
  • 二十四节气组诗 谷雨 离陌_6639
    图片来源网络，若侵犯了你的权益，请联系我删除6.谷雨文/离陌背上行囊背上如行囊的我从此任行程马不停蹄今天家乡的田野春雨快马加鞭播下希望的种子观音不语目送着我和夏天一道在观音山出关图片来源网络，若侵犯了你的权益，请联系我删除你好啊，我是离陌，已然在懵懂中走过了16年的岁月，为了珍惜当下的每一秒，所以立志做一名终身学习者。文学对于我来说是一种信仰，诗歌是我的生命。人生之道，四通八达，即入文学，自当持之
  • 你好，2020年 瑄瑄妍妍的妈咪
    早上好，今天是2020年的第一天，也就是元旦，新年新的一天开始了。新的开始，重新规划未来的一年。从今天开始，用了一个新的记账软件，之前的随手记软件，也没有删除，只是重新下载了一个别的软件，开始一个新的记账旅程，对于理财开支，有个新的规划。通过小红书视频软件，学习了不少育儿知识，和各种不同的美食，以后动手制作，给宝宝做健康美味的营养餐。学习方面，继续学英语吧！虽然是抽出时间学的，进度也比较慢，但是积
  • Effective C++ 条款10：令operator=返回一个reference to *this 君鼎 C++c++
    EffectiveC++条款10：令operator=返回一个referenceto*this核心思想：赋值操作符（operator=）应始终返回当前对象的引用（*this），以实现连锁赋值并保持与内置类型一致的语义。⚠️1.问题场景：违反连锁赋值语义classWidget{public:voidoperator=(constWidget&rhs){//错误：返回voidvalue=rhs.val
  • 常规笔记本和加固笔记本的区别 luchengtech 电脑三防笔记本加固计算机加固笔记本
    在现代科技产品中，笔记本电脑因其便携性和功能性被广泛应用。根据使用场景和需求的不同，笔记本可分为常规笔记本和加固笔记本，二者在多个方面存在显著区别。适用场景是区分二者的重要标志。常规笔记本主要面向普通消费者和办公人群，适用于家庭娱乐、日常办公、学生学习等相对稳定的室内环境。比如，人们在家用它追剧、处理文档，学生在教室用它完成作业。而加固笔记本则专为特殊行业设计，像军事、野外勘探、工业制造、交通运输
  • 《云襄传》：云襄做的局是浑水摸鱼吗？ 书生号贺
    云襄入南都是要浑水摸鱼吗？他是云台的高材生吗？他为啥笃定师父一定会让他留在南都？他为啥觉得他能够做局成功？他是在经商吗？还是在经营人心与欲望？云襄是云台弟子，云台属千门的一支，另一支叫凌渊，云台教人经商之道，重智慧，凌渊以武力取胜，但倍受打压。云襄学习十五年，下高山奔越州，途经南洋，因恩人闻聪被害，囚于白驹镇，念于情分，被卷入这样一个局面里，结识了舒亚南与金十两，于是，复仇小组成立，目标是南都漕帮
  • C++ ：vector的模拟 诚自然成 c++开发语言
    目录一、vector的迭代器二、vector的构造函数默认构造函数参数构造函数迭代器范围构造函数拷贝构造函数swap:交换vector重载赋值符析构函数reserve:扩容vectorresize:调整大小push_back:添加元素empty:判空pop_back:后删获取大小与容量：size(),capacity()重载operator[]：元素访问insert：插入元素erase:删除一个元
  • 心力践行营十二期一阶学习打卡 LX_王彤彤
    姓名：王彤彤时间：2021年4月24日一：朗读师父的十大人生哲学二：师父的早安分享感悟很喜欢这句话：所有的行动都是基于目标的尝试，没有所谓的失败，只是不同尝试后得到的不同结果，让我们更好地调整下一次的行动。三：感恩日记1.我太幸福了，我很感恩姑姑，因为姑姑放假又投喂了我，还给我带了饺子回家，这让我感觉很幸福。谢谢，谢谢，谢谢。2.我太幸福了，我很感恩师父晚上的直播，因为听他的分享我知道怎么更好的去
  • 为了在未来的人工智能世界中取得成功，学生们必须学习人类写作的优点 睿邸管家
    澳大利亚各地的学生在新学年开始使用铅笔、钢笔和键盘学习写字。在工作场所，机器也在学习写作，如此有效，几年之内，它们可能会写得比人类更好。有时它们已经做到了，就像Grammarly这样的应用程序所展示的那样。当然，人类现在的日常写作可能很快就会由具有人工智能(AI)的机器来完成。手机和电子邮件软件常用的预测文本是无数人每天都在使用的一种人工智能写作形式。据AI行业研究机构称，到2022年，人工智能及
  • 闭组进行时... 李亚青_强化班
    今天是2019年12月1号距离开始三月学习的日子:2019年10月07,已经过去将近两个月，回顾这一阶段的学习，收获了什么?又学会了什么呢?图片发自App我想，收获最大的就是身边这一群人吧,有和蔼可亲的学姐，贴心的学长，嬉戏打闹，玩的不亦乐乎，但也同样认真踏实学习小伙伴图片发自App本以为在这样的时刻，有太多太多话，太多太多想法想要表达，可言到此处，又觉得似乎没有什么想要说的了还是那句话，幸运遇到
  • 2021-10-23 赵甄文的幸福
    秀荣感恩日记Day42[烟花]感恩语录感恩自己有能力有好身体，可以到处走动，做自己想做的事情10.23感恩日记今天做的事情瑜伽一小时户外散步一小时泡脚20分钟学习打卡和孩子沟通[爱心]感动的瞬间今天瑜伽回来，发现老公在厨房里做鱼。每次老公有时间休息的时候都会给我做硬菜。刘姐约我一起去公园散步晒太阳。虽然完美错过，但心里还是暖暖的。每天睁开眼打开手机，先去自己的群里逛一逛，每每发现有人点赞或者互动都
  • 孤独的守候 怒吼的生命
    孤独了时光岁月了寂寞带来了惆怅那些孤独的日子里我们珍惜奋斗起来品味人生的真谛做到更好奋斗当中的你是那么努力格外自律学习起来五彩斑斓那些日子时光匆匆人生的机会很多需要把握痛苦的回忆记得住那些忧愁孤苦五一的日子寂寞当中的你时光荏苒独自带给我荒草学习起来努力奋斗可是我们做的还不够把握发展生活带给我们更多希望静静的述说你的故事你的精彩人生当中我们总是努力把握生活带给我们更多的学习生活当中我们奋斗可是做的还
  • AI模型训练中过拟合和欠拟合的区别是什么？ workflower 人工智能算法人工智能数据分析
    在AI模型训练中，过拟合和欠拟合是两种常见的模型性能问题，核心区别在于模型对数据的学习程度和泛化能力：欠拟合（Underfitting）-定义：模型未能充分学习到数据中的规律，对训练数据的拟合程度较差，在训练集和测试集上的表现都不好（如准确率低、损失值高）。-原因：-模型结构过于简单（如用线性模型解决非线性问题）；-训练数据量不足或特征信息不充分；-训练时间太短，模型尚未学到有效模式。-表现：训练
  • 2018-08-29精进打卡 米兰王
    姓名:王兰英【日精进打卡第25天】【知～学习】《六项精进》1遍共39遍《大学》1遍共50遍【经典名句分享】一切都是最好的安排。【行～实践】一、修身：（对自己个人）1，散步1小时。2，每天坚持读书。二、齐家：（对家庭和家人）1，指导孩子开车。2，和家人一起逛超市。三、建功：（对工作）用心做好每件事。｛积善｝：发愿从2018年8月5日起1年内365个善事。今日1善，累计27善。【省～觉悟】正人先正己。
  • 陶勇：要不要参加分班考试学习？看完再说。 陶勇
    每年到了升学季，有很多培训机构都特别忙，为什么呢？因为有成千上万的学生，会选择升学前的分班考试的培训。比如说，小升初的孩子，到了暑假，很多孩子都会去选择一个初中，初一的分班考试的培训，那考入高中的孩子也有很多孩子会选择这种新高一的分班考试的培训。当然了，我个人认为这种选择并不是孩子自身的选择，主要还是家长的选择。当然也有少数孩子会对自己有比较高的要求，他们也会主动的去选择。为什么要去上分班考试的这
  • C++编程基础与面向对象概念解析 侯昂 面向对象编程C++语法函数类与对象继承与多态性
    C++编程基础与面向对象概念解析背景简介C++是一种广泛使用的面向对象编程语言，它允许开发者创建高效、灵活且功能强大的程序。本文基于《C++Primer》一书的章节内容，深入解析C++的核心概念和面向对象编程原则，旨在帮助读者构建扎实的C++编程基础。面向对象编程的原则软件危机与进化介绍了软件危机的产生和软件进化的必要性，强调了面向对象编程（OOP）在应对这些问题中的优势。面向对象编程范式讨论了面
  • Anaconda 和 Miniconda：功能详解与选择建议 古月฿ python入门pythonconda
    Anaconda和Miniconda详细介绍一、Anaconda的详细介绍1.什么是Anaconda？Anaconda是一个开源的包管理和环境管理工具，在数据科学、机器学习以及科学计算领域发挥着关键作用。它以Python和R语言为基础，为用户精心准备了大量预装库和工具，极大地缩短了搭建数据科学环境的时间。对于那些想要快速开展数据分析、模型训练等工作的人员来说，Anaconda就像是一个一站式的“数
  • PHP，安卓，UI，java，linux视频教程合集 cocos2d-x小菜 javaUIPHPandroidlinux
    ╔-----------------------------------╗┆                           
  • 各表中的列名必须唯一。在表 'dbo.XXX' 中多次指定了列名 'XXX'。 bozch .net.net mvc
    在.net mvc5中，在执行某一操作的时候，出现了如下错误：       各表中的列名必须唯一。在表 'dbo.XXX' 中多次指定了列名 'XXX'。 经查询当前的操作与错误内容无关，经过对错误信息的排查发现，事故出现在数据库迁移上。 回想过去： 在迁移之前已经对数据库进行了添加字段操作，再次进行迁移插入XXX字段的时候，就会提示如上错误。  &
  • Java 对象大小的计算 e200702084 java
                              Java对象的大小 如何计算一个对象的大小呢？    
  • Mybatis Spring 171815164 mybatis
    ApplicationContext ac = new ClassPathXmlApplicationContext("applicationContext.xml"); CustomerService userService = (CustomerService) ac.getBean("customerService"); Customer cust
  • JVM 不稳定参数 g21121 jvm
            -XX 参数被称为不稳定参数，之所以这么叫是因为此类参数的设置很容易引起JVM 性能上的差异，使JVM 存在极大的不稳定性。当然这是在非合理设置的前提下，如果此类参数设置合理讲大大提高JVM 的性能及稳定性。        可以说“不稳定参数”
  • 用户自动登录网站 永夜-极光 用户
    1.目标:实现用户登录后,再次登录就自动登录,无需用户名和密码 2.思路:将用户的信息保存为cookie            每次用户访问网站,通过filter拦截所有请求,在filter中读取所有的cookie,如果找到了保存登录信息的cookie,那么在cookie中读取登录信息,然后直接
  • centos7 安装后失去win7的引导记录 程序员是怎么炼成的 操作系统
    1.使用root身份(必须)打开 /boot/grub2/grub.cfg 2.找到 ### BEGIN /etc/grub.d/30_os-prober ###   在后面添加    menuentry "Windows 7 (loader) (on /dev/sda1)" { 
  • Oracle 10g 官方中文安装帮助文档以及Oracle官方中文教程文档下载 aijuans oracle
    Oracle 10g 官方中文安装帮助文档下载：http://download.csdn.net/tag/Oracle%E4%B8%AD%E6%96%87API%EF%BC%8COracle%E4%B8%AD%E6%96%87%E6%96%87%E6%A1%A3%EF%BC%8Coracle%E5%AD%A6%E4%B9%A0%E6%96%87%E6%A1%A3 Oracle 10g 官方中文教程
  • JavaEE开源快速开发平台G4Studio_V3.2发布了 無為子 AOPoraclemysqljavaeeG4Studio
      我非常高兴地宣布,今天我们最新的JavaEE开源快速开发平台G4Studio_V3.2版本已经正式发布。大家可以通过如下地址下载。   访问G4Studio网站 http://www.g4it.org   G4Studio_V3.2版本变更日志 功能新增 (1).新增了系统右下角滑出提示窗口功能。 (2).新增了文件资源的Zip压缩和解压缩
  • Oracle常用的单行函数应用技巧总结 百合不是茶 日期函数转换函数(核心)数字函数通用函数(核心)字符函数
    单行函数;   字符函数,数字函数,日期函数,转换函数(核心),通用函数(核心) 一:字符函数: .UPPER(字符串) 将字符串转为大写 .LOWER (字符串) 将字符串转为小写 .INITCAP(字符串) 将首字母大写 .LENGTH (字符串) 字符串的长度 .REPLACE(字符串,'A','_') 将字符串字符A转换成_
  • Mockito异常测试实例 bijian1013 java单元测试mockito
    Mockito异常测试实例： package com.bijian.study; import static org.mockito.Mockito.mock; import static org.mockito.Mockito.when; import org.junit.Assert; import org.junit.Test; import org.mockito.
  • GA与量子恒道统计 Bill_chen JavaScript浏览器百度Google防火墙
    前一阵子，统计**网址时，Google Analytics（GA） 和量子恒道统计（也称量子统计），数据有较大的偏差，仔细找相关资料研究了下，总结如下：   为何GA和量子网站统计（量子统计前身为雅虎统计）结果不同？ 首先：没有一种网站统计工具能保证百分之百的准确出现该问题可能有以下几个原因：（1）不同的统计分析系统的算法机制不同；（2）统计代码放置的位置和前后
  • 【Linux命令三】Top命令 bit1129 linux命令
    Linux的Top命令类似于Windows的任务管理器，可以查看当前系统的运行情况，包括CPU、内存的使用情况等。如下是一个Top命令的执行结果：     top - 21:22:04 up 1 day, 23:49, 1 user, load average: 1.10, 1.66, 1.99 Tasks: 202 total, 4 running, 198 sl
  • spring四种依赖注入方式 白糖_ spring
      平常的java开发中，程序员在某个类中需要依赖其它类的方法，则通常是new一个依赖类再调用类实例的方法，这种开发存在的问题是new的类实例不好统一管理，spring提出了依赖注入的思想，即依赖类不由程序员实例化，而是通过spring容器帮我们new指定实例并且将实例注入到需要该对象的类中。依赖注入的另一种说法是“控制反转”，通俗的理解是：平常我们new一个实例，这个实例的控制权是我
  • angular.injector boyitech AngularJSAngularJS API
    angular.injector   描述: 创建一个injector对象, 调用injector对象的方法可以获得angular的service, 或者用来做依赖注入.   使用方法: angular.injector(modules, [strictDi])   参数详解: Param Type Details mod
  • java-同步访问一个数组Integer[10]，生产者不断地往数组放入整数1000，数组满时等待；消费者不断地将数组里面的数置零，数组空时等待 bylijinnan Integer
    public class PC { /** * 题目：生产者-消费者。 * 同步访问一个数组Integer[10]，生产者不断地往数组放入整数1000，数组满时等待；消费者不断地将数组里面的数置零，数组空时等待。 */ private static final Integer[] val=new Integer[10]; private static
  • 使用Struts2.2.1配置 Chen.H apachespringWebxmlstruts
    Struts2.2.1 需要如下 jar包: commons-fileupload-1.2.1.jar commons-io-1.3.2.jar commons-logging-1.0.4.jar freemarker-2.3.16.jar javassist-3.7.ga.jar ognl-3.0.jar spring.jar struts2-core-2.2.1.jar struts2-sp
  • [职业与教育]青春之歌 comsci 教育
           每个人都有自己的青春之歌............但是我要说的却不是青春...        大家如果在自己的职业生涯没有给自己以后创业留一点点机会,仅仅凭学历和人脉关系,是难以在竞争激烈的市场中生存下去的....   &nbs
  • oracle连接(join)中使用using关键字 daizj JOINoraclesqlusing
    在oracle连接(join)中使用using关键字 34. View the Exhibit and examine the structure of the ORDERS and ORDER_ITEMS tables. Evaluate the following SQL statement: SELECT oi.order_id, product_id, order_date FRO
  • NIO示例 daysinsun nio
    NIO服务端代码： public class NIOServer { private Selector selector; public void startServer(int port) throws IOException { ServerSocketChannel serverChannel = ServerSocketChannel.open(
  • C语言学习homework1 dcj3sjt126com chomework
    0、 课堂练习做完 1、使用sizeof计算出你所知道的所有的类型占用的空间。 int x; sizeof(x);   sizeof(int);   # include <stdio.h> int main(void) { int x1; char x2; double x3; float x4; printf(&quo
  • select in order by , mysql排序 dcj3sjt126com mysql
    If i select like this: SELECT id FROM users WHERE id IN(3,4,8,1); This by default will select users in this order 1,3,4,8, I would like to select them in the same order that i put IN() values so:
  • 页面校验-新建项目 fanxiaolong 页面校验
    $(document).ready( function() { var flag = true; $('#changeform').submit(function() { var projectScValNull = true; var s =""; var parent_id = $("#parent_id").v
  • Ehcache（02）——ehcache.xml简介 234390216 ehcacheehcache.xml简介
    ehcache.xml简介          ehcache.xml文件是用来定义Ehcache的配置信息的，更准确的来说它是定义CacheManager的配置信息的。根据之前我们在《Ehcache简介》一文中对CacheManager的介绍我们知道一切Ehcache的应用都是从CacheManager开始的。在不指定配置信
  • junit 4.11中三个新功能 jackyrong java
    junit 4.11中两个新增的功能，首先是注解中可以参数化，比如 import static org.junit.Assert.assertEquals; import java.util.Arrays; import org.junit.Test; import org.junit.runner.RunWith; import org.junit.runn
  • 国外程序员爱用苹果Mac电脑的10大理由 php教程分享 windowsPHPunixMicrosoftperl
    Mac 在国外很受欢迎，尤其是在 设计/web开发/IT 人员圈子里。普通用户喜欢 Mac 可以理解，毕竟 Mac 设计美观，简单好用，没有病毒。那么为什么专业人士也对 Mac 情有独钟呢？从个人使用经验来看我想有下面几个原因： 1、Mac OS X 是基于 Unix 的 这一点太重要了，尤其是对开发人员，至少对于我来说很重要，这意味着Unix 下一堆好用的工具都可以随手捡到。如果你是个 wi
  • 位运算、异或的实际应用 wenjinglian 位运算
    一． 位操作基础，用一张表描述位操作符的应用规则并详细解释。       二． 常用位操作小技巧，有判断奇偶、交换两数、变换符号、求绝对值。       三． 位操作与空间压缩，针对筛素数进行空间压缩。    &n
  • weblogic部署项目出现的一些问题（持续补充中……） Everyday都不同 weblogic部署失败
    好吧，weblogic的问题确实……   问题一： org.springframework.beans.factory.BeanDefinitionStoreException: Failed to read candidate component class: URL [zip:E:/weblogic/user_projects/domains/base_domain/serve
  • tomcat7性能调优（01） toknowme tomcat7
        Tomcat优化： 1、最大连接数最大线程等设置 <Connector port="8082" protocol="HTTP/1.1"                useBodyEncodingForURI="t
  • PO VO DAO DTO BO TO概念与区别 xp9802 javaDAO设计模式bean领域模型
    O/R Mapping 是 Object Relational Mapping（对象关系映射）的缩写。通俗点讲，就是将对象与关系数据库绑定，用对象来表示关系数据。在O/R Mapping的世界里，有两个基本的也是重要的东东需要了解，即VO，PO。 它们的关系应该是相互独立的，一个VO可以只是PO的部分，也可以是多个PO构成，同样也可以等同于一个PO（指的是他们的属性）。这样，PO独立出来，数据持
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他