调试模式下为std::vector和std::array的operator[]添加范围检查

针对你需要在Debug模式下为std::vector和std::array的operator[]添加范围检查、Release模式无额外开销的需求，推荐以下两种可靠方案：

方案一：局部启用_GLIBCXX_DEBUG（推荐，无代码修改） #

_GLIBCXX_DEBUG会让libstdc++的STL容器启用调试模式（包括operator[]的范围检查），但第三方库冲突问题可以通过编译隔离解决：将你的性能关键代码和第三方库（如yaml-cpp）分开编译，仅给你的代码添加_GLIBCXX_DEBUG宏，第三方库保持正常编译。

实现方式（以CMake为例） #

# 第三方库（如yaml-cpp）使用正常编译选项，不添加调试宏
# 若为外部依赖，确保其编译时未启用_GLIBCXX_DEBUG
add_library(yaml-cpp STATIC IMPORTED)
# 或自行编译yaml-cpp时使用默认编译配置

# 你的目标代码，仅在Debug模式下启用_GLIBCXX_DEBUG
add_executable(your_perf_app src/your_code.cpp)
target_compile_definitions(your_perf_app PRIVATE
    $<$<CONFIG:Debug>:_GLIBCXX_DEBUG>
)
# 链接第三方库的正常版本
target_link_libraries(your_perf_app yaml-cpp)

优点 #

• 无需修改任何业务代码，直接使用原生std::vector和std::array
• Debug模式下享受libstdc++原生的完整调试检查（不止operator[]，还有迭代器合法性等）
• Release模式完全等价于原生容器，无任何额外开销

注意事项 #

• 必须确保启用_GLIBCXX_DEBUG的代码和未启用的代码（第三方库）分开编译，因为调试模式下STL容器的内存布局和正常版本不同，混合链接会导致未定义行为。

方案二：通用包装器类（跨编译器，无STL依赖） #

如果无法控制编译流程或需要跨编译器兼容，可编写一个轻量包装器类，对std::vector和std::array进行封装，仅在Debug模式下添加范围检查。

实现代码 #

#include <vector>
#include <array>
#include <cassert>
#include <utility>
#include <functional>

template <typename Container>
class DebugChecked {
private:
    Container m_inner;

public:
    // 转发所有构造函数
    template <typename... Args>
    constexpr DebugChecked(Args&&... args) noexcept(std::is_nothrow_constructible_v<Container, Args...>)
        : m_inner(std::forward<Args>(args)...) {}

    // 通过operator->直接访问底层容器的所有成员函数
    constexpr Container* operator->() noexcept { return &m_inner; }
    constexpr const Container* operator->() const noexcept { return &m_inner; }

    // Debug模式下带范围检查的operator[]
#ifndef NDEBUG
    constexpr decltype(auto) operator[](size_t idx) & noexcept {
        assert(idx < m_inner.size());
        return m_inner[idx];
    }

    constexpr decltype(auto) operator[](size_t idx) const& noexcept {
        assert(idx < m_inner.size());
        return m_inner[idx];
    }

    constexpr decltype(auto) operator[](size_t idx) && noexcept {
        assert(idx < m_inner.size());
        return std::move(m_inner[idx]);
    }
#else
    // Release模式直接转发，无任何额外开销
    constexpr decltype(auto) operator[](size_t idx) & noexcept { return m_inner[idx]; }
    constexpr decltype(auto) operator[](size_t idx) const& noexcept { return m_inner[idx]; }
    constexpr decltype(auto) operator[](size_t idx) && noexcept { return std::move(m_inner[idx]); }
#endif
};

// 类型别名简化使用
template <typename T>
using CheckedVector = DebugChecked<std::vector<T>>;

template <typename T, size_t N>
using CheckedArray = DebugChecked<std::array<T, N>>;

使用示例 #

// 代替std::vector<int> vec;
CheckedVector<int> vec(10);
vec->push_back(42); // 通过operator->调用底层vector的成员函数
int val = vec[5];   // Debug模式下检查索引，Release模式直接访问

// 代替std::array<double, 5> arr;
CheckedArray<double, 5> arr;
arr[3] = 3.14; // Debug模式下检查索引（0-4）

优点 #

• 不继承STL容器（避免STL无虚析构带来的风险），安全可靠
• 同时支持std::vector和std::array，无需单独实现
• Debug模式下仅添加assert检查，Release模式完全等价于原生容器
• 跨编译器兼容，不依赖libstdc++的内部实现

为什么不推荐你的派生类方案？ #

1. STL容器无虚析构：std::vector没有虚析构函数，若用std::vector<T>*指向Vector<T>对象，析构时会跳过派生类的析构逻辑，导致资源泄漏。
2. 依赖STL内部实现：你直接访问了_M_impl._M_start，这是libstdc的私有内部成员，不同版本的libstdc可能会修改该实现，导致代码不可移植。

内容的提问来源于stack exchange，提问作者ander