C++实现区间最大值RMQ查询算法 _ 线段树与ST表实现【实战】

C++实现区间最大值RMQ查询算法 _ 线段树与ST表实现【实战】

ST表预处理为什么必须用log2(i)向下取整

这里有个关键细节必须厘清：ST表的f[i][j]定义，是从起点i开始、长度为2^j的区间最大值。当我们要查询任意区间[l, r]时，需要找到两个长度为2^k的重叠子区间来覆盖它，而这个k，必须是floor(log2(r - l + 1))。如果这里用了向上取整或者四舍五入，结果要么覆盖不全，要么直接越界访问，整个查询就全错了。

一个特别容易踩的坑，是直接写成int k = log2(r - l + 1)。要知道，C++标准库里的log2返回的是double类型，浮点误差在边界值上会带来灾难。比如，当区间长度恰好是65536时，log2(65536)理论上等于16，但浮点运算可能返回15.999999，一旦被int强制截断，就变成了15。用这个错误的k去查表，得到的结果自然南辕北辙。

• 正确做法一（GCC/Clang）：利用内置函数31 - __builtin_clz(r - l + 1)，专为整数设计，又快又准。
• 正确做法二（通用）：预处理一个log2_table数组，比如for (int i = 2; i <= n; i++) log2_table[i] = log2_table[i / 2] + 1;，用空间换确定性和速度。
• 核心原则：别直接用std::log2的结果做数组索引计算，除非你明确做了四舍五入（如round()），并且能确保输入值不为零。

ST表预处理必须用log₂(i)向下取整，因为fi定义为[i, i+2^j−1]区间最值，查询[l,r]时需取最大k使2^k≤r−l+1，即k=⌊log₂(r−l+1)⌋；若向上取整或浮点截断错误（如log2(65536)返回15.9999→int得15），会导致覆盖不足或越界。

线段树build时递归边界写错导致query返回0或随机值

线段树建树过程中的递归边界，是个老生常谈却又屡屡出错的地方。典型错误是，虽然区间定义写的是[l, r]，递归调用也写了build(l, mid)和build(mid+1, r)，但问题出在mid = (l + r) / 2这个整数除法上。当l == r时，mid可能就等于l，如果终止条件if (l == r)的位置放得不对，或者根本没写，递归就会陷入死循环，最终导致栈溢出或访问越界。

更隐蔽的坑，藏在节点的存储方式里。如果用vector tree，并且以索引1作为根节点，左儿子是2*node，那么数组大小至少要开到4 * n。如果只开2 * n，在递归查询时，有很大概率会访问到未初始化的内存区域，返回莫名其妙的0或者脏数据。

• 递归终止检查：务必确保if (l == r) { tree[node] = a[l]; return; }这条语句放在递归调用之前。
• 数组大小：宁可多开，别省那点内存。直接用tree.resize(4 * n)，别轻信“理论上2n就够”的说法，实践中极易出错。
• 区间定义一致性：query函数里如果用了if (r < ql || l > qr)来判断无交集，一定要明确你用的是闭区间[l, r]还是左闭右开[l, r)。RMQ问题通常使用闭区间，切忌混用。

立即学习“C++免费学习笔记（深入）”；

ST表比线段树快，但不支持修改，连单点更新都不行

这是选择数据结构时必须权衡的核心问题。ST表的本质是一个静态的、基于倍增思想的动态规划表。它的状态转移f[i][j] = max(f[i][j-1], f[i + (1 << (j-1))][j-1])完全依赖于初始的输入数组。一旦某个原始值a[i]发生改变，所有包含这个位置的状态，也就是整个f[i][*]以及所有覆盖了位置i的f[k][j]，理论上都需要重新计算。这个更新代价是O(n log n)，比暴力遍历区间还要糟糕。

所以，面对“需要查询区间最大值”这个需求，首先要问清楚几个关键点：数据后续会不会修改？查询是否强制在线（即边改边查）？有没有严格的内存或时间限制？

• 纯离线批量查询：比如在线评测系统（OJ）上的一道题，数组只读入一次，然后进行高达10万次查询。这种情况，无脑用ST表就对了。预处理O(n log n)，每次查询O(1)，效率碾压。
• 带更新的场景：如果有单点更新甚至区间更新的需求，那就只能请出线段树了。或者，在特定场景下也可以考虑分块算法，实现O(sqrt(n))的查询和更新复杂度。
• 资源极度受限：比如在嵌入式环境，内存紧张，且查询次数极少。这时候，直接O(n)遍历区间求最值，可能比费劲建ST表更省空间、更简单直接。

ST表二维数组怎么开才不MLE（尤其n=1e6时）

当数据规模n达到1e6时，内存消耗就成了一个现实挑战。第二维j的最大值大约是log2(1e6) ≈ 20。如果简单地声明一个int f[n][21]，理论内存占用约为1e6 * 21 * 4 bytes ≈ 84MB，这很容易超过许多在线评测系统常见的64MB内存限制。

优化的核心思路在于内存布局。既然状态转移时，j只依赖于j-1，理论上可以滚动数组，只保留两层。但更通用的做法是使用一维数组来模拟二维：

vector f(n * LOGN);
#define F(i, j) f[(i) * LOGN + (j)] // 宏定义来方便访问

不过，最务实的方案可能是“按需分配”：对于每个起始位置i，只存储到其合法的最大j（即满足i + (1 << j) - 1 < n的最大j）。可以用vector> f(n)，然后为每个f[i]单独resize(max_j_i + 1)。这种方法通常能节省30%以上的内存。

• 避免静态大数组：别用int f[1000000][21]这样的全局声明，它会被放入BSS段，在部分编译环境下可能导致链接失败或内存超限。
• 预定义常量：LOGN建议直接定义为20或21这样的常量，不要用ceil(log2(n))在运行时计算，既避免误差也提升效率。
• 明确上限：如果n不确定但存在明确上限（比如#define MAXN 1000000），就直接按上限开数组或分配vector，不要试图在运行时动态推导二维大小，增加复杂度。

总的来说，ST表的常数开销确实远小于线段树，但其二维数组的内存布局和对数计算的细节，比初看起来要更容易出错。调试时经常遇到的情况是：f[0][0]的值是对的，但f[0][1]却是0——这十有八九是中间值mid算错了，或者某个边界条件没有卡死。魔鬼，往往就藏在这些细节里。