我对这个问题产生兴趣的起因是 Codeoforces Avito Challenges 2018 的 E 题，我想到了正解，但写得太慢，最后一刻才提交。有个地方写错，结果是 Runtime error on pretest 13。
那个错误是个数组越界。代码片段如下：

    #define rng(i, a, b) for(int i = (a); i < (b); ++i)vv<pii> fact(2e5+5);// 计算 factvv<bool> dp(m, vb(ma));    // m 和 ma 是正整数vv<int> pre(m, vi(ma));rng (i, 0, SZ(fact[a[0]])) {dp[0][i] = true;}rng(i, 0, m) {  // 错误出在这里auto &cur = fact[a[i]];auto &nxt = fact[a[i + 1]]; rng(j, 0, SZ(fact[a[i]])) {if(dp[i][j]) {int t = cur[j].second;for (int k = 0; k < SZ(nxt); k++) {if(t < nxt[k].first) {dp[i+1][k] = true;pre[i+1][k] = j;}}}}}

那个 for 循环本应是 rng(i, 0, m-1) 。我的写法通过了三个样例，交上去在 pretest 13 RE 了。仓促改了另外一个地方又交上去结果在 pretest 2 就 RE 了。数组越界这个问题什么时候会触发 RE 是不确定的。

赛后我想起曾经看到过 std::vector 会自动检查数组越界，可是我在 CLion 中编译运行上面的代码为何运行时没提示数组越界呢，况且 CLion 的 Run/Debug Configurations 还显示处于 Debug 模式。

图-1

图中红线框出的那里，左边的 algo 是当前选择的 target 的名字，target 是在 CMakeLists.txt 中定义的。红框圈起来的东西，官方名称 是 run/debug configuration selector。

图-2

于是我搜了一下怎样开启数组越界检查。在 StackOverflow 上找到一个答案。办法就是编译时加上选项 _GLIBCXX_DEBUG 其实这是个宏定义，不必作为 g++ 的命令行选项， 在代码里加上 #define _GLIBCXX_DEBUG 也可以，和其他宏定义没区别，只不过会被编译器识别，并对编译器产生影响。

我加了这个宏定义再编译运行原来的代码，果然就报错了。不过并没有指明错误是由那一行代码引起的，对于 debug 帮助不大，这个问题请移步这里。不过虽然未能指出是那一行代码出的错，但是指出了是访问 3 这个位置越界了，那么就说明对应的 vector 的 size 应该是 3，这个信息对于这道题目的 debug 仍然很有帮助，据此可以知道这个 3 是 m 的值。

图-3

我的疑问是 CLion 的 Build/Debug Configurations 框里的那个 Debug 到底是什么含义（What does it imply?）先看看这个 Debug 究竟是什么含义。

首先要介绍 CLion 中的一个重要概念 Run/Debug Configrations。

To run or debug your code in CLion, you can use numerous run/debug configurations. Each run/debug configuration represents a named set of run/debug startup properties. When you perform run, debug, or test operations with CLion, you always start a process based on one of the existing configurations using its parameters.

CLion comes with a number of run/debug configuration types for the various running, debugging and testing issues. You can create your own run/debug configurations of specific types.

关于 Run/Debug Configurations 的更多细节，见 Create and Edit Configurations。

其实 图-1 红框里的那个 Debug 是当前所选择的 configuration 所采用的 CMake profile 的名字。可以在下图中的加号（+）上面看到 “profiles” 字样。

图-4

上图是 CMake settings dialog。

当然这个 name 是可以改的，比如改成 debug，那么第一幅图红框里也会相应地由 Debug 变成 debug。

现在我们收集到的信息有

• 图-1 中的 Debug 字样代表的是当前的 configuration 所采用的 CMake profile。
• 这个 CMake profile 名为 "Debug" 是因为所选的 build type 是 Debug。
• CMake profile 中的 build option 应当是传给编译器的。

现在我们要问：当 build type 为 Debug 时，是否会把类似于 _GLIBCXX_DEBUG 这样的选项传递给编译器呢？

答案是不会。

我们可以从 CLion 文档中关于 build type 的页面上示例代码中推测出来

图-5

关于 图-4 中的 build option -j 6，CLion 文档是这样解释的：

Build options In this text field, specify the options to be passed to the build tool used by CMake.
Find more information about the available build options in the CMake documentation.

If nothing is specified, the default settings are used. Note, that default settings depend on the selected environment. For example, if make generator is selected, the default value is -j <number_of_cpu>, while for Microsoft Visual C++ the field is empty.

我采用的 toolchain 是 MinGW，所用的 generator 自然是 make，另外我的 laptop 的 CPU 是 Intel Core i7-8750H，# of Cores = 6，因此默认的 build option 是 -j 6 。

在 CMake 文档里关于 CMAKE_BUILD_TYPE 这个 variable 的说明页面，我找到线索

... For example, in a build tree configured to build type Debug, CMake will see to having CMAKE_C_FLAGS_DEBUG settings get added to the CMAKE_C_FLAGS settings.

我猜当 build type 是 Debug 时 CMake 只是把 -g 之类的调试选项传给编译器了。

结论

Run/Debug Configurations 是控制可执行文件生成以后的执行与调试的，而 Build Configurations 是控制从源代码生成可执行文件的过程的。我应该去修改 Build Configrations 也就是 CMake profile，比如可以把 -D_GLIBCXX_DEBUG 添加到 Build option。在代码中加上 #define _GLIBCXX_DEBUG 也是可行的。

Reference

Catching silly mistakes with GCC
C++ и bounds checking