C++23新特性实践：从std::expected到模块化

背景与问题界定

一个持续6年以上迭代的C++量化交易库面临两个核心痛点：第一，函数返回值和错误分离的方式在不同模块中极不统一——有的返回std::optional+errno、有的返回std::pair<Result, ErrorCode>、有的返回负数表示错误、有的直接throw异常（但在性能路径上catch的代价不可接受）。C++23的std::expected提供了标准化的"值或错误"返回类型，可以统一这些混乱的错误处理模式。第二，项目头文件依赖森林越来越深——一个简单的#include <trade_engine.hpp>可能递归include超过500个头文件，增量编译时间超过35秒。C++20的模块（modules）虽然已经提出，但工具链支持直到C++23才真正成熟可用。我们需要衡量将核心模块迁移到C++23的收益与风险。

目标拆解与工程约束

std::expected的异常替代范围：std::expected<T, E>适用于"可能失败的正常控制流"（如解析、校验、类型转换），但不适合替代"不可恢复的错误"（如系统级故障）——这些场景仍然需要异常。需要明确划分expected和throw的适用边界，避免两端同时使用导致接口混乱。
模块化迁移的ABI问题：C++20模块会改变符号可见性和inline行为。导出import的模块与#include的头文件在同一TU中可能产生符号冲突（ODR violation）。迁移到模块化必须是以module为单位的全量迁移，不能逐文件partial transition。
std::print和std::format的编译期收益：C++23将std::print（基于std::format）标准化，可以替代大部分printf和iostream的日志输出场景。std::format的编译期参数解析比printf的类型不安全格式串和iostream的运行时虚函数调用都有显著优势。需要量化基准。
std：：mdspan和std：：flat_map的性能验证：新的容器和视图std::mdspan（多维数组视图）和std::flat_map（基于排序vector的map）在内存局部性上优于传统方案。但flat_map的插入复杂度O(n)意味着它不能直接替代std::unordered_map，必须按访问模式选择。

方案设计

错误处理统一采用std::expected模式。API边界上，所有"可能因输入数据问题而失败"的函数返回expected<T, domain_error>，而"因系统资源不足而失败"的函数保留异常。为了平滑迁移，我们为C++17兼容的调用方提供expected的backport实现（基于tl::expected），并在C++23模式下通过#if __cpp_lib_expected >= 202211L条件编译切换到标准库实现。

// 使用std::expected解析市场数据
#include <expected>
#include <string_view>

enum class ParseError { InvalidFormat, MissedField, OutOfRange };

struct TradeTick {
    int64_t timestamp;
    double price;
    uint32_t volume;
};

auto parse_tick(std::string_view line) -> std::expected<TradeTick, ParseError> {
    auto sep1 = line.find(',');
    if (sep1 == std::string_view::npos) return std::unexpected(ParseError::InvalidFormat);
    
    auto price = std::from_chars(line.data() + sep1 + 1, line.data() + line.size(), sep1);
    // 使用std::from_chars 零分配解析
    // ...
    return TradeTick{ .timestamp = ts, .price = p, .volume = v };
}

// 调用方使用and_then链式处理
void process_ticks(std::span<const std::string_view> lines) {
    for (auto& line : lines) {
        auto result = parse_tick(line)
            .and_then([](TradeTick tick) -> std::expected<void, ParseError> {
                engine_.feed(tick);
                return {};
            })
            .or_else([](ParseError err) -> std::expected<void, ParseError> {
                log_warn("Parse failed: {}", static_cast<int>(err));
                return {};  // 错误被消耗，不中断循环
            });
    }
}

模块化迁移方面，我们采用"自顶向下"策略：先从最底层的"基础类型和工具"模块开始，该模块没有#include依赖（仅import <std>），随后逐层向上迁移业务模块。CMake通过CXX_STANDARD 23和set(CMAKE_CXX_MODULE_STD 1)启用模块化构建。

# CMakeLists.txt 模块化构建示例
cmake_minimum_required(VERSION 3.28)
project(trade_engine VERSION 2.0 LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_MODULE_STD 1)

# 编译核心模块
add_library(trade_engine_core)
target_sources(trade_engine_core PRIVATE
    FILE_SET CXX_MODULES FILES
    modules/trade_engine.core.cppm
    modules/trade_engine.types.cppm
)

实施路径与关键决策

先迁移错误处理模式，再迁移模块化：std::expected的迁移是纯语法/API层面的，风险更低，可以先在2周内完成。模块化迁移涉及构建系统变更和更长的编译配置调试期，放在第二阶段。
std::flat_map仅用于静态配置数据：对于启动后不常变动的路由表和合约定义使用flat_map，利用其连续内存布局和二分查找（O(log n)）优势。对于运行时频繁插入的动态数据，继续使用std::unordered_map。

验证指标与可持续迭代

迁移后，核心解析路径上的错误处理代码量减少45%，异常路径覆盖率从67%提升到测试框架中的expected式链路测试可覆盖100%的输入数据有效性边界。模块化迁移完成后，trade_engine_core模块的增量编译时间从35秒降到6秒。持续监控C++23标准库在不同编译器版本上的特性兼容性，使用__cpp_lib_*宏做策略性fallback。

工程落地思考

C++23不是一个颠覆性的版本，而是C++20的成熟化——那些在C++20中提出但工具链支持不完善的功能（模块化、std::format的持续扩展、std::expected）终于在C++23中达到了"可生产使用"的阶段。升级到C++23看起来只是调整CMAKE_CXX_STANDARD的一行配置，但实际收益取决于你在多大程度上拥抱这些标准化了的模式——用std::expected取代混乱的错误返回半成品，用模块化打破30年来的头文件依赖噩梦，用std::print告别类型不安全的printf。语言标准升级最大的回报不是新语法，而是这些语法背后所代表的"社区共识的设计模式"。