在讨论《string 的长度比 int 数组大吗》回复：

@[_Seren_](luogu://user/1794511) 动态扩容的内存是临时分配的，而且你完全可以使用预分配技术避免动态扩容。这个时候和 `char` 数组基本没有区别。

在讨论《string 的长度比 int 数组大吗》回复：

@[_Seren_](luogu://user/1794511) 就按照单字节数组看就行。 对于 `char` 数组，占用的字节数就是数组长度。 对于 `std::string`，其是动态分配内存，因此可以按最大大小进行计算。需要注意的是，`std::string` 还有一些辅助数据，不要卡点计算大小。 **动态扩容的…

在讨论《string 的长度比 int 数组大吗》回复：

@[yanghechen](luogu://user/1686806) 不是下标太大，而是 `int` 占用四个字节，而 `char` 只占用一个。这是四倍的内存差距。

在讨论《string 的长度比 int 数组大吗》回复：

@[I_do_Cpp](luogu://user/1433656)@[anke2017](luogu://user/1076971) `std::string` 的长度限制是你的计算机内存绝对达不到的程度。`std::string` 的长度限制是 `std::size_t` 类型的上限。在 64 位操作系统上，`std…

在讨论《string 的长度比 int 数组大吗》回复：

@[anke2017](luogu://user/1076971) 不需要很长，本来就是一样的。不过 `std::string` 是动态分配而已。

在讨论《string 的长度比 int 数组大吗》回复：

@[I_do_Cpp](luogu://user/1433656) 哪怕 `std::string` 实在堆上分配内存，这部分内存也是计入程序运行时内存的。 只不过你可以把 `std::string` 看作是一个 `std::vector ` 而已。 `char` 是一字节的，而 `int` 是四字节的。

在讨论《将变量名设为中文竟然不报错》回复：

@[Grammar_hbw](luogu://user/856004) 这些乱码是在 Windows 上使用 GBK 编码格式进行字符串输出的时候，访问非法内存或忘记初始化内存导致的，与代码中使用 Unicode 字符无关。

在讨论《将变量名设为中文竟然不报错》回复：

@[wwsz_zxc](luogu://user/1771865) GCC 作为现代 C++ 编译器的一种，早就支持 Unicode 了。

在讨论《将变量名设为中文竟然不报错》回复：

@[snowlov](luogu://user/1405202) 第一，问类似问题之前先搜索或询问 AI。 第二，你不是第一个在这里惊叹 Unicode 支持的人了。如果 C++ 到现在还不支持 Unicode，它早就应该被淘汰了。 第三，CLion 是 IDE（集成开发环境），集成了 C++ 的 LSP（Langua…

在讨论《为什么CE》回复：

@[kongliheng](luogu://user/1425185) 注意区分关键字（保留字）和标识符。 下次可以尝试不使用命名空间导入，而是显式使用 `std::` 前缀明确命名空间。这样能避免绝大多数的 C++ 标准库名称冲突。命名空间就是为了这个而产生的。 当然，对于 C 语言遗留接口（如 `printf`）在…

在讨论《为什么CE》回复：

@[Ethan0824](luogu://user/1077096) 不是哥们，区分一下关键字和标识符好吗？ （无恶意） 标准库中已经存在了这两个东西，换句话说，标准库已经定义了这两个标识符的具体含义，你再定义就是属于命名冲突了。 关键字指的是 `if`、`else`、`while` 这些在一个编程语言中被强制保留用作…

在讨论《求助灵异事件》回复：

@[QEDQEDQED](luogu://user/1320489)@[StеlІаwіnD](luogu://user/222865)@[shiyilang0910](luogu://user/1243587)@[_ATRI](luogu://user/2029033) 空间局部性问题。第二份代码，由于访问的内存都是…

在讨论《关于std queue》回复：

@[f_an_kaiyuan_](luogu://user/774230)@[b1tset](luogu://user/697898)@[_Kagamine_Rin_](luogu://user/260985) 空间复杂度：程序可能执行的最大大小。 有效数据占用：与 `size()` 相同。 实际数据占用：比 `cap…

在讨论《cstdint 你的跨平台~》回复：

@[litjohn](luogu://user/537934) 其实我有一种比较极客的写法，当然也只在小程序（如竞赛程序）中使用： ```cpp line-numbers #define long long long ``` 写在头文件之后，避免宏污染。 之前学系统变成的时候，Linux 上使用 `long` 已经用习…

在讨论《为什么这代码又双叒叕能过编译啊》回复：

@[Daniope1266](luogu://user/1024631) 计算表达式 `a[y]` 时 `y` 是随机值，理论上任何在 `int` 范围内的数字都有可能，比如超出 $2 \times 10^9$ 的值或负数。

在讨论《为什么这代码又双叒叕能过编译啊》回复：

@[hali13](luogu://user/1062722) C++ 编译器是先声明后定义，所以其代码等同于： ```cpp line-numbers int y; y = a[y]; // 此时 y 是随机值。 ```

在讨论《关于头文件》回复：

@[Cute_Wazzy](luogu://user/1169959) 666

在讨论《关于#define int long long》回复：

@[Chemical_Block](luogu://user/1849906) 可以。 建议配合 `cin` 和 `cout` 使用，避免格式字符错误。 注意空间限制以及 `long long` 比 `int` 多的运算性能损耗。

在讨论《问》回复：

@[dingziyang888](luogu://user/1633534) 新的 C++ 本来就支持 Unicode 字符。 实际上你会发现，好像除了老一点的 Pascal 和以前的 C/C++，几乎所有的常用编程语言都支持 Unicode 字符。 Julia 语言甚至可以： ```julia line-number…

在讨论《关于头文件》回复：

@[Cute_Wazzy](luogu://user/1169959) 在头文件里加宏定义就不怕宏污染吗？一不小心把标准库代码给替换了那会出现什么奇怪的东西谁也不知道。 下次用宏记得放在源文件中所有头文件的 `include` 后面，能很大程度避免宏污染。这个东西比与标准库撞名还可怕。

在讨论《关于 vscode》回复：

插件问题，联系开发者。暂时可用 Code Runner 代替。

在讨论《人类一败涂地》回复：

疑似集体被 jc。

在讨论《关于文章防伪》回复：

感谢。

在讨论《函数内存管理？》回复：

@[OIer_FightForOI](luogu://user/1546551) 改智能指针。

在讨论《std::bad_alloc 求助》回复：

@[01bit](luogu://user/338147) `std::bad_alloc` 是 C++ 标准异常，在动态分配内存失败时出现。有可能是空栈弹出，也有可能在动态回收内存时出现错误。 不过这个要具体阅读 C++ 标准。

在讨论《有没有dalao解救一下蒟蒻的码风》回复：

@[I2147483647I](luogu://user/1446352) 我可以尝试帮你改一下。但由于根据变量名无法推断原始含义（元素周期表？），而且我也懒得去再做一遍题目，所以没有改变量名，只改了格式。以下是我习惯的代码风格。 第一段代码： ```cpp line-numbers #include #include…

在讨论《为什么本地开1e9的bitset会ce》回复：

@[langmou](luogu://user/1393704) `.bss`段（可以理解为可执行程序中用于存储静态全局变量的位置）可能过大，尝试改为动态分配内存，并查看是否仍然报错。

在讨论《为什么本地开1e9的bitset会ce》回复：

@[langmou](luogu://user/1393704) `cc1plus` 是你的可执行程序名称吗？ 代码中是否有其他分配内存的部分？ 也可能是 `.bss` 段过大，尝试在堆上动态分配一致大小的内存，查看是否仍然报错。

在讨论《为什么本地开1e9的bitset会ce》回复：

@[langmou](luogu://user/1393704) 请确认这是否是编译错误的报错信息，这看起来像是运行时错误。 如果确实是编译器所发出的错误信息，则可能是编译器在编译过程中分配过多内存被操作系统终止。

在讨论《为什么本地开1e9的bitset会ce》回复：

@[langmou](luogu://user/1393704) 检查您的编译器位宽，是否为 32 位。 请提供编译报错信息。