C/C++编译器在什么情况下不会重排语句？
好的，我们来聊聊C/C++编译器在什么情况下会“老实”地按照我们写的顺序来执行语句，而不是擅自“搬运”它们。
其实，现代编译器为了榨干CPU性能，会进行大量的优化，其中就包括指令重排。这就像一个勤快的工头，为了让工人们（CPU核心）更有效率，会把任务调整一下顺序，争取让等待时间最短。但是，有些时候，这种“勤快”是会被阻止的，或者说，我们有办法让编译器乖乖地按照顺序来。
以下是几种主要的情况，在这些情况下，C/C++编译器通常不会重排语句：
1. 明确的内存顺序（Memory Order Constraints）
这是最直接、也是最根本的理由。在多线程编程中，我们经常需要确保多个线程对共享内存的访问是按照预期顺序进行的。编译器之所以敢重排，是因为它认为在单线程环境下，或者在没有明确内存依赖的情况下，重排不会改变程序的逻辑结果。但一旦涉及到跨线程的共享数据，事情就变得复杂了。
C++11引入了 `std::atomic` 类型以及相关的内存顺序（memory order）参数，就是为了解决这个问题。当你使用带有特定内存顺序的原子操作时，你就告诉了编译器：“嘿，这个操作以及它之前的某些操作，必须先于这个操作之后的操作执行，而且不能被搬到后面去！”
`std::memory_order_seq_cst` (Sequentially Consistent): 这是最强的内存顺序。它保证了全局的、统一的顺序，所有线程都会看到所有原子操作以同一个顺序发生。编译器绝对不会重排发生在 `seq_cst` 操作之前的、影响到该操作的语句，也不会将 `seq_cst` 操作之后的相关语句移到其前面。这有点像一个“绝对禁止”的标签，什么都别想在我前面发生，什么也别想在我后面发生。
`std::memory_order_acquire` / `std::memory_order_release`: 这对组合通常用于实现锁或者标志位的同步。`release` 操作确保其之前的写操作对后续的 `acquire` 操作可见，并且 `acquire` 操作之后的操作不会被重排到 `acquire` 操作之前。
`std::memory_order_acq_rel`: 结合了 `acquire` 和 `release` 的功能。
举个例子：
```c++
include
include
include
std::atomic data{0};
std::atomic ready{false};
void writer() {
data.store(10, std::memory_order_release); // 写入数据，并标记为“准备好”
ready.store(true, std::memory_order_release);
}
void reader() {
while (!ready.load(std::memory_order_acquire)) { // 等待“准备好”标志
// 忙等待...
}
// 此时，compiler cannot reorder data.load() to happen before ready.load()
// And it cannot reorder anything after ready.load() to before it.
int val = data.load(std::memory_order_acquire); // 读取数据
std::cout << "Read value: " << val << std::endl;
}
int main() {
std::thread t1(writer);
std::thread t2(reader);
t1.join();
t2.join();
return 0;
}
```
在这个例子中，`ready.store(true, std::memory_order_release)` 之前的所有写操作（比如 `data.store(10, std::memory_order_release)`）都会被“绑定”住，不能被重排到 `ready.store` 之后。同样，`ready.load(std::memory_order_acquire)` 之后的操作（比如 `data.load()`）也不会被重排到 `ready.load` 之前。
2. 数据依赖（Data Dependencies）
这是编译器在优化时最基本的规则之一。如果一个语句的结果被后续的语句所使用，那么编译器通常不会将这个后续语句的执行顺序“提到”其依赖的前面。如果重排了，那么后续语句获取到的就是“旧的”或者“错误的结果”，这会直接导致程序的逻辑错误。
直接数据依赖: 语句 B 使用了语句 A 的输出作为输入。
反向数据依赖: 语句 B 写入了语句 A 之前读取的同一个变量，并且语句 A 的结果依赖于这个变量的旧值。
输出数据依赖: 语句 B 和语句 A 都写入同一个变量。
举个例子：
```c++
int a = 5;
int b = a + 2; // b 依赖于 a 的值
int c = b 3; // c 依赖于 b 的值
```
在这里，`b` 的计算必须在 `a` 的赋值之后进行。`c` 的计算必须在 `b` 的计算之后进行。编译器知道这一点，所以它不会把 `c = b 3;` 这行代码“挪到” `b = a + 2;` 的前面。如果它这么做了，`b` 的值还没计算出来，`c` 就无法正确计算。
3. 控制依赖（Control Dependencies）
当一个语句的执行与某个条件判断（如 `if` 语句、循环的条件）相关联时，编译器也需要小心处理。如果一条语句的执行与否，或者它的具体执行内容，依赖于某个条件判断的结果，那么编译器通常不会将其重排到条件判断之前，除非它能证明重排不会改变控制流。
例子1：
```c++
if (condition) {
statement_a;
}
statement_b; // statement_b 的执行可能依赖于 statement_a 的执行（尽管这里不是直接数据依赖，而是逻辑上的）
```
编译器可能会重排 `statement_b`，但如果 `statement_b` 是 `statement_a` 的结果的消费者，或者 `statement_b` 本身是另一个影响控制流的语句，编译器就会谨慎。
更严格的控制依赖:
```c++
int x = 10;
if (x > 0) {
x = 20; // 语句 A
}
int y = x + 5; // 语句 B
```
编译器知道 `y` 的值取决于 `x` 在 `if` 语句之后的最终值。它不会把 `y = x + 5;` 挪到 `if (x > 0)` 之前，因为那样 `x` 可能还没有被赋值，或者 `if` 语句的条件判断可能还没执行。
4. 引入“障碍”（Barriers）的指令或关键字
除了 `std::atomic` 的内存顺序，还有一些更底层的机制可以强制实现顺序：
`asm volatile("" ::: "memory");` (GCC/Clang)：这是在GCC和Clang中常用的一种“禁令”。`asm volatile("" ...)` 语句本身不做任何事情，它只是一个空的汇编块。`"memory"` 约束告诉编译器，这个汇编块会“读写”或“影响”内存中的所有变量。因此，编译器必须确保在该汇编块之前的所有内存访问（读写）都完成，并且不能将该汇编块之后的内存访问“提前”到之前。这就像在你的代码流程中插入了一个“内存栅栏”，迫使编译器在它之前完成所有与内存相关的操作。
```c++
int x = 1;
int y = 2;
// 编译器可能会重排 x 和 y 的读写
asm volatile("" ::: "memory"); // 插入内存栅栏
// 之后的操作，编译器必须确保之前的内存操作都已完成
int z = x + y;
```
在这里，`asm volatile("" ::: "memory");` 会阻止编译器将 `z = x + y;` 的计算（或者说，`x` 和 `y` 的读取）挪到 `asm volatile` 之前。
compiler intrinsics（编译器内建函数）: 某些特定的内建函数（如用于SIMD指令的函数）可能带有隐含的内存顺序保证，或者需要特定的指令来确保操作顺序。
5. C/C++标准中定义的非重排行为
C/C++ 标准本身也对某些操作的顺序性做出了规定。例如：
函数调用: 在一个函数调用之前的所有语句，原则上会按顺序执行完毕，然后才会进入函数体。函数调用返回后，才会执行调用点之后的语句。虽然函数体内可以有重排，但函数调用本身是一个“序列点”，它分隔了函数调用之前和之后的操作。
表达式的副作用: C++标准规定了表达式中子表达式求值的顺序（尽管具体顺序可能在某些情况下仍然可以被优化，但某些序列点强制了执行顺序）。例如，在 `a() + b()` 中，`a()` 和 `b()` 的求值顺序在 C++17 之前是不确定的，但 C++17 之后，`a()` 和 `b()` 的求值顺序是确定的（从左到右），如果它们有副作用。但更重要的是，如果一个语句的副作用会影响后续语句的执行（例如，改变后续语句的输入），编译器会考虑这种依赖。
赋值运算符的序列点: 某些赋值运算符（如 `&&`、`||`、`?:`）引入了序列点，它们强制了其中一部分的求值必须在另一部分之前完成。
6. 优化级别（Optimization Levels）
需要注意的是，编译器是否会进行重排，以及重排的程度，很大程度上取决于编译器的优化级别（如 `O0`, `O1`, `O2`, `O3`）。
`O0` (No Optimization): 在这个级别，编译器进行的重排非常少，它会尽可能地按照源代码的顺序来生成机器码。这是调试时最常用的级别。
`O1`, `O2`, `O3` (Optimization Levels): 随着优化级别的提高，编译器会越发激进地进行重排，以追求更高的性能。
总结一下，编译器不会重排语句的主要原因可以归结为：
为了维护程序的逻辑正确性（数据依赖、控制依赖）。
为了满足多线程环境下的同步要求（原子操作的内存顺序）。
通过特定的指令或关键字（如 `asm volatile("memory")`）强行插入“障碍”。
C/C++ 标准本身定义的序列点和求值顺序。
理解这些，就能更好地控制程序的行为，特别是在并发和性能敏感的场景下。记住，当你想让编译器“乖乖听话”时，通常需要付出一定的性能代价（例如 `std::memory_order_seq_cst` 比 `memory_order_relaxed` 慢）。
其实，现代编译器为了榨干CPU性能，会进行大量的优化，其中就包括指令重排。这就像一个勤快的工头，为了让工人们（CPU核心）更有效率，会把任务调整一下顺序，争取让等待时间最短。但是，有些时候，这种“勤快”是会被阻止的，或者说，我们有办法让编译器乖乖地按照顺序来。
以下是几种主要的情况，在这些情况下，C/C++编译器通常不会重排语句：
1. 明确的内存顺序（Memory Order Constraints）
这是最直接、也是最根本的理由。在多线程编程中，我们经常需要确保多个线程对共享内存的访问是按照预期顺序进行的。编译器之所以敢重排，是因为它认为在单线程环境下，或者在没有明确内存依赖的情况下，重排不会改变程序的逻辑结果。但一旦涉及到跨线程的共享数据，事情就变得复杂了。
C++11引入了 `std::atomic` 类型以及相关的内存顺序（memory order）参数，就是为了解决这个问题。当你使用带有特定内存顺序的原子操作时，你就告诉了编译器：“嘿，这个操作以及它之前的某些操作，必须先于这个操作之后的操作执行，而且不能被搬到后面去！”
`std::memory_order_seq_cst` (Sequentially Consistent): 这是最强的内存顺序。它保证了全局的、统一的顺序，所有线程都会看到所有原子操作以同一个顺序发生。编译器绝对不会重排发生在 `seq_cst` 操作之前的、影响到该操作的语句，也不会将 `seq_cst` 操作之后的相关语句移到其前面。这有点像一个“绝对禁止”的标签，什么都别想在我前面发生，什么也别想在我后面发生。
`std::memory_order_acquire` / `std::memory_order_release`: 这对组合通常用于实现锁或者标志位的同步。`release` 操作确保其之前的写操作对后续的 `acquire` 操作可见，并且 `acquire` 操作之后的操作不会被重排到 `acquire` 操作之前。
`std::memory_order_acq_rel`: 结合了 `acquire` 和 `release` 的功能。
举个例子：
```c++
include
include
include
std::atomic
std::atomic
void writer() {
data.store(10, std::memory_order_release); // 写入数据，并标记为“准备好”
ready.store(true, std::memory_order_release);
}
void reader() {
while (!ready.load(std::memory_order_acquire)) { // 等待“准备好”标志
// 忙等待...
}
// 此时，compiler cannot reorder data.load() to happen before ready.load()
// And it cannot reorder anything after ready.load() to before it.
int val = data.load(std::memory_order_acquire); // 读取数据
std::cout << "Read value: " << val << std::endl;
}
int main() {
std::thread t1(writer);
std::thread t2(reader);
t1.join();
t2.join();
return 0;
}
```
在这个例子中，`ready.store(true, std::memory_order_release)` 之前的所有写操作（比如 `data.store(10, std::memory_order_release)`）都会被“绑定”住，不能被重排到 `ready.store` 之后。同样，`ready.load(std::memory_order_acquire)` 之后的操作（比如 `data.load()`）也不会被重排到 `ready.load` 之前。
2. 数据依赖（Data Dependencies）
这是编译器在优化时最基本的规则之一。如果一个语句的结果被后续的语句所使用，那么编译器通常不会将这个后续语句的执行顺序“提到”其依赖的前面。如果重排了，那么后续语句获取到的就是“旧的”或者“错误的结果”，这会直接导致程序的逻辑错误。
直接数据依赖: 语句 B 使用了语句 A 的输出作为输入。
反向数据依赖: 语句 B 写入了语句 A 之前读取的同一个变量，并且语句 A 的结果依赖于这个变量的旧值。
输出数据依赖: 语句 B 和语句 A 都写入同一个变量。
举个例子：
```c++
int a = 5;
int b = a + 2; // b 依赖于 a 的值
int c = b 3; // c 依赖于 b 的值
```
在这里，`b` 的计算必须在 `a` 的赋值之后进行。`c` 的计算必须在 `b` 的计算之后进行。编译器知道这一点，所以它不会把 `c = b 3;` 这行代码“挪到” `b = a + 2;` 的前面。如果它这么做了，`b` 的值还没计算出来，`c` 就无法正确计算。
3. 控制依赖（Control Dependencies）
当一个语句的执行与某个条件判断（如 `if` 语句、循环的条件）相关联时，编译器也需要小心处理。如果一条语句的执行与否，或者它的具体执行内容，依赖于某个条件判断的结果，那么编译器通常不会将其重排到条件判断之前，除非它能证明重排不会改变控制流。
例子1：
```c++
if (condition) {
statement_a;
}
statement_b; // statement_b 的执行可能依赖于 statement_a 的执行（尽管这里不是直接数据依赖，而是逻辑上的）
```
编译器可能会重排 `statement_b`，但如果 `statement_b` 是 `statement_a` 的结果的消费者，或者 `statement_b` 本身是另一个影响控制流的语句，编译器就会谨慎。
更严格的控制依赖:
```c++
int x = 10;
if (x > 0) {
x = 20; // 语句 A
}
int y = x + 5; // 语句 B
```
编译器知道 `y` 的值取决于 `x` 在 `if` 语句之后的最终值。它不会把 `y = x + 5;` 挪到 `if (x > 0)` 之前，因为那样 `x` 可能还没有被赋值，或者 `if` 语句的条件判断可能还没执行。
4. 引入“障碍”（Barriers）的指令或关键字
除了 `std::atomic` 的内存顺序，还有一些更底层的机制可以强制实现顺序：
`asm volatile("" ::: "memory");` (GCC/Clang)：这是在GCC和Clang中常用的一种“禁令”。`asm volatile("" ...)` 语句本身不做任何事情，它只是一个空的汇编块。`"memory"` 约束告诉编译器，这个汇编块会“读写”或“影响”内存中的所有变量。因此，编译器必须确保在该汇编块之前的所有内存访问（读写）都完成，并且不能将该汇编块之后的内存访问“提前”到之前。这就像在你的代码流程中插入了一个“内存栅栏”，迫使编译器在它之前完成所有与内存相关的操作。
```c++
int x = 1;
int y = 2;
// 编译器可能会重排 x 和 y 的读写
asm volatile("" ::: "memory"); // 插入内存栅栏
// 之后的操作，编译器必须确保之前的内存操作都已完成
int z = x + y;
```
在这里，`asm volatile("" ::: "memory");` 会阻止编译器将 `z = x + y;` 的计算（或者说，`x` 和 `y` 的读取）挪到 `asm volatile` 之前。
compiler intrinsics（编译器内建函数）: 某些特定的内建函数（如用于SIMD指令的函数）可能带有隐含的内存顺序保证，或者需要特定的指令来确保操作顺序。
5. C/C++标准中定义的非重排行为
C/C++ 标准本身也对某些操作的顺序性做出了规定。例如：
函数调用: 在一个函数调用之前的所有语句，原则上会按顺序执行完毕，然后才会进入函数体。函数调用返回后，才会执行调用点之后的语句。虽然函数体内可以有重排，但函数调用本身是一个“序列点”，它分隔了函数调用之前和之后的操作。
表达式的副作用: C++标准规定了表达式中子表达式求值的顺序（尽管具体顺序可能在某些情况下仍然可以被优化，但某些序列点强制了执行顺序）。例如，在 `a() + b()` 中，`a()` 和 `b()` 的求值顺序在 C++17 之前是不确定的，但 C++17 之后，`a()` 和 `b()` 的求值顺序是确定的（从左到右），如果它们有副作用。但更重要的是，如果一个语句的副作用会影响后续语句的执行（例如，改变后续语句的输入），编译器会考虑这种依赖。
赋值运算符的序列点: 某些赋值运算符（如 `&&`、`||`、`?:`）引入了序列点，它们强制了其中一部分的求值必须在另一部分之前完成。
6. 优化级别（Optimization Levels）
需要注意的是，编译器是否会进行重排，以及重排的程度，很大程度上取决于编译器的优化级别（如 `O0`, `O1`, `O2`, `O3`）。
`O0` (No Optimization): 在这个级别，编译器进行的重排非常少，它会尽可能地按照源代码的顺序来生成机器码。这是调试时最常用的级别。
`O1`, `O2`, `O3` (Optimization Levels): 随着优化级别的提高，编译器会越发激进地进行重排，以追求更高的性能。
总结一下，编译器不会重排语句的主要原因可以归结为：
为了维护程序的逻辑正确性（数据依赖、控制依赖）。
为了满足多线程环境下的同步要求（原子操作的内存顺序）。
通过特定的指令或关键字（如 `asm volatile("memory")`）强行插入“障碍”。
C/C++ 标准本身定义的序列点和求值顺序。
理解这些，就能更好地控制程序的行为，特别是在并发和性能敏感的场景下。记住，当你想让编译器“乖乖听话”时，通常需要付出一定的性能代价（例如 `std::memory_order_seq_cst` 比 `memory_order_relaxed` 慢）。
网友意见
重排跟volatile没关系。
volatile是为了阻止编译器把取值操作给优化掉。
如果要保证语句顺序，唯一的办法是加mb（atomic或者锁，内部也是靠mb保证这点）。
类似的话题
-
好的，我们来聊聊C/C++编译器在什么情况下会“老实”地按照我们写的顺序来执行语句，而不是擅自“搬运”它们。其实，现代编译器为了榨干CPU性能，会进行大量的优化，其中就包括指令重排。这就像一个勤快的工头，为了让工人们（CPU核心）更有效率，会把任务调整一下顺序，争取让等待时间最短。但是，有些时候，这............. -
说起现代C/C++编译器有多“聪明”，其实与其说是聪明，不如说是它在几十年的发展中，通过无数经验的积累和算法的精进，进化出了令人惊叹的“技艺”。这些技艺的核心目标只有一个：让你的程序跑得更快、用更少的内存，或者两者兼顾。我们来掰开了揉碎了聊聊，这些“聪明”的编译器到底能干些啥厉害的事情。1. 代码的.............
-
第一个C语言编译器的开发背景与历史背景密切相关，其编写语言的选择与当时的技术环境、资源限制以及开发者的目标密切相关。以下是详细的分析： 1. C语言的起源与背景C语言由Dennis Ritchie（丹尼斯·里奇）在1972年于贝尔实验室开发，作为B语言的改进版本。B语言本身是Ken Thompson.............
-
想亲手敲打出自己的编译器，这绝对是个值得挑战的目标！除了《编译原理》这本“圣经”之外，还有很多宝贵的资源可以助你一臂之力。下面我给你扒一扒，并且一步步告诉你该怎么下手，目标是用 C/C++ 来实现。 除了《编译原理》，你还需要什么“兵器”？《编译原理》虽然是基础，但它更多的是告诉你“为什么”和“是什.............
-
要找“最短”又“导致崩溃”且“编译器无法优化掉”的 C++ 代码，这其中包含几个关键点，我们需要逐一拆解，才能理解为什么会出现这种情况，以及如何达到这种效果。首先，我们得明白，“崩溃”在 C++ 中通常意味着程序执行过程中遇到了不可恢复的错误，最常见的就是访问了无效的内存地址（比如空指针解引用、越界.............
-
手机上C语言运行 `while(system("pause"))` 导致重启，这个问题涉及到几个关键点：`system()` 函数的本质、`pause` 命令在Android环境下的表现、以及手机操作系统的资源管理和稳定性机制。 让我们一层层剥开来看，还原一下这个现象背后的逻辑。首先，我们要明白 `.............
-
当然可以，C语言作为一门编译型语言，其强大的跨平台能力很大程度上得益于其设计理念和标准库。通过遵循一定的规则，并且在不同平台上都拥有能够解析和生成对应机器码的编译器，C语言的源代码确实能够实现跨平台运行。这背后的原理可以从几个关键点来理解：1. C语言的标准化与抽象层：C语言之所以能实现跨平台，最根.............
-
要回答这个问题，我们得掰开了揉碎了讲。以前，尤其是在机械硬盘时代，编译慢这事儿，硬盘绝对是脖子上的那根绳，能把你勒得喘不过气。但现在，固态硬盘（SSD）都普及了，C++编译的速度瓶颈，那可就不是简单地说“还在硬盘I/O”这么一句话能概括得了的了。首先，咱们得理解 C++ 编译是个啥过程。 它不是一蹴.............
-
要用同一个 `Makefile` 在 Windows 和 Linux 下编译和链接 C++ 项目，我们需要充分利用 `Makefile` 的灵活性，并通过一些条件判断和工具来适配两个平台上的差异。这主要涉及到编译器、路径分隔符、链接库的查找方式等问题。以下我将详细讲解如何实现这一点，并尽量让内容更像.............
-
.......
-
好的，我们来聊聊《C专家编程》第六十页讲到的参数传递到寄存器的问题。这可不是什么“AI”的套路，而是计算机底层运作的真实写照。想象一下，你给CPU下达命令，让它处理一些数据，比如计算两个数的和。这些“数据”就是我们说的参数。为什么参数首先要去寄存器呢？简单来说，寄存器是CPU内部速度最快、最容易访问.............
-
.......
-
当然，这种将一种编程语言先转换成C代码，然后再由C编译器生成最终可执行文件的路径，在计算机科学领域是完全可行的，而且在历史上和实践中都扮演着重要的角色。想象一下，你有一种全新的编程语言，它有着自己独特的语法、语义和设计理念。你希望它能够运行起来，并且能够利用现有的硬件和操作系统能力。直接为这种语言编.............
-
这是一个非常有趣且值得深入探讨的问题。从技术上讲，C++编译器可以被设计成弃用指针，只允许使用引用。 但要详细说明这一点，我们需要从几个核心层面来理解：C++语言的设计哲学、引用的本质以及指针的不可替代性。 语言设计的自由度与约束首先，需要明确的是，C++作为一门编程语言，其语法和特性是由标准委员会.............
-
要评价《王垠：C 编译器优化过程中的 Bug》这篇技术文章，我们需要从多个维度进行深入分析。这篇技术文章（通常指的是王垠在其博客或其他平台发表的关于 C 编译器优化问题的讨论）的核心在于揭示编译器在进行复杂优化时可能引入的软件缺陷，以及这些缺陷对程序行为的潜在影响。文章的核心内容与主要观点：王垠在其.............
-
const 的守护之剑：编译器如何雕琢 C/C++ 中的不变之道在C/C++的世界里，`const` 并非只是一个简单的关键字，它更像一把锋利的守护之剑，承诺着数据的不可变性，为程序的稳定性和可维护性筑起一道坚实的壁垒。那么，这把剑究竟是如何被铸造和挥舞的呢？这背后，是编译器一系列精巧的设计和严密的.............
-
选择一个“好用”的C语言编译器，很大程度上取决于你的具体需求、你想要开发的平台以及你个人对工具的偏好。没有一个绝对完美的编译器适合所有人，但有一些在业界广受好评且功能强大的选项，我会详细介绍一下，并尽量从一个真实使用者的角度来分享我的感受和看法。在我看来，衡量一个C编译器好用的标准主要包括以下几个方.............
-
C 语言中指针加一这看似简单的操作，背后隐藏着计算机底层的工作原理。这并不是简单的数值加一，而是与内存的组织方式和数据类型紧密相关。要理解指针加一，我们首先需要明白什么是“指针”。在 C 语言里，指针本质上是一个变量，它存储的是另一个变量的内存地址。你可以把它想象成一个房间号，这个房间号指向的是实际.............
-
好的，咱们就来聊聊 SDCC（Small Device C Compiler）这个编译器套件，好好掰扯掰扯它的斤两。别看它名字里有“Small Device”，这玩意儿可是不少嵌入式开发者，特别是那些跟资源受限的微控制器打交道的硬核玩家心中的宝贝。SDCC 是什么来头？简单来说，SDCC 是一个用 .............
-
这个问题很有意思，也很常被讨论。不能简单地说MSVC“做不好”C语言编译器，这其中涉及到历史、商业策略、生态系统以及技术选择等多方面的因素。下面我来详细聊聊为什么大家普遍认为MSVC在功能支持和性能上不如GCC/Clang，以及微软在这方面的一些考量。 功能支持的差异：为什么感觉MSVC“落后”？要.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有