C++实现环形队列CircularQueue _ 数组下标取模运算【源码】-C++-PHP中文网

环形队列中front/rear不能直接++因需模运算绕回，但负数取模可能为负，应使用(x%n+n)%n或条件判断；空满判据不能都用front==rear，须预留冗余位或引入size；new t[n]需手动析构避免泄漏；应使用unique_ptr和construct_at/destroy_at支持移动与异常安全。

c++实现环形队列circularqueue _ 数组下标取模运算【源码】

为什么环形队列的 `front` 和 `rear` 不能直接用 `++i` 后自增？

因为环形本质是数组首尾相连，下标必须始终落在 [0, capacity) 范围内。直接自增会越界，必须靠取模运算“绕回”。但取模有陷阱：C++ 中负数取模结果可能为负（如 -1 % 5 == -1），而数组下标不能为负。所以不能写 front = (front - 1) % capacity 这类表达式。

实操建议：

统一用 (x % n + n) % n 做安全取模，确保结果恒为非负
更高效的做法是用条件判断替代取模：当 rear == capacity - 1 时置 0，否则 ++rear；但会增加分支，对高频操作有微小性能影响
推荐封装成内联辅助函数：inline int mod(int x, int n) { return (x % n + n) % n; }

`isFull()` 和 `isEmpty()` 的判据为什么不能都用 `front == rear`？

这是环形队列最易错的设计点。单靠 front == rear 无法区分空和满——两者状态完全一致。必须预留一个“冗余槽位”或引入额外字段（如计数器 size）来打破歧义。

实操建议：

主流做法是牺牲一个元素空间：队列最大有效容量为 capacity - 1，用 (rear + 1) % capacity == front 判满，用 front == rear 判空
若坚持物理满容（即 capacity 个元素），必须加 size 成员变量，此时 isFull() 直接返回 size == capacity，isEmpty() 返回 size == 0
前者节省内存、逻辑简洁；后者避免容量浪费，但多一次内存访问（读 size）

构造函数里用 `new T[capacity]` 分配元素，为什么必须配合 `std::destroy` 或手动析构？

因为 new T[n] 会调用 T 的默认构造函数初始化每个元素，而环形队列实际只在入队时才真正使用某位置的元素。如果用户类型 T 构造开销大（如含 std::string 或动态分配），提前全量构造就是浪费；更严重的是，出队后该位置对象仍处于“已构造未析构”状态，再次入队前若不显式析构，会造成资源泄漏或未定义行为。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

实操建议：

改用 std::allocator<t></t> + allocate()/construct()/destroy() 手动控制生命周期
或者用 std::vector<:byte></:byte> 配合 std::construct_at 和 std::destroy_at（C++20）
简单起见，也可要求 T 必须是 trivially destructible，跳过析构步骤——但需文档明确标注限制