为什么C++的 extern "C" 里面可以使用C里面不存在的STL和引用&等C++才有的特性 ?
你提出的这个问题很有意思，涉及到 C++ 和 C 之间的接口以及 `extern "C"` 的作用。简单来说，`extern "C"` 的核心功能是指示编译器在进行名称修饰（name mangling）时，遵循 C 语言的规则，而不是 C++ 的规则。它本身并不限制你在 C++ 代码块中使用的语言特性，而是控制外部链接（external linkage）时符号的表示方式。
为了把这个问题讲清楚，我们需要一步步来剖析：
1. C++ 和 C 的名称修饰（Name Mangling）差异
这是理解 `extern "C"` 关键的基础。
C 语言： C 语言的标准非常简洁，它不进行名称修饰。一个函数或全局变量的符号名就是它在源代码中的名字。例如，一个名为 `my_function` 的函数，在编译后生成的对象文件中，它的符号名就是 `my_function`（可能前面会加上一个下划线，这取决于具体的平台和编译器，但核心是名字本身）。
C++ 语言： C++ 为了支持函数重载（overloading）、命名空间（namespaces）、类成员函数（member functions）等特性，引入了名称修饰（name mangling 或 name decoration）的机制。编译器会将函数的参数类型、const/volatile 等信息编码到函数名中，生成一个唯一的符号名。
函数重载： 如果你有 `void func(int x)` 和 `void func(double y)` 两个函数，C++ 编译器会将它们变成不同的符号，例如 `_Z4funci` 和 `_Z4funcd`（这是一个GCC风格的例子）。这样，在链接时，链接器就能区分并找到正确的函数。
命名空间： 位于不同命名空间下的同名函数也会被区分开。
类成员函数： 类成员函数会被修饰，以包含类名和参数信息。
举个例子：
假设你在 C++ 中有一个函数：
```c++
void greet(int id) {
// ...
}
```
在 C++ 环境下编译，这个 `greet` 函数在对象文件中生成的符号名可能不是 `greet`，而是类似 `_Z5greethi` 这样的。
2. `extern "C"` 的真正作用：控制链接
`extern "C"` 的核心是告诉 C++ 编译器：请为这个函数（或变量）生成 C 语言风格的符号名，而不是 C++ 风格的名称修饰后的符号名。
当你写下：
```c++
extern "C" void c_style_function(int x) {
// ... 这是C++代码
}
```
这句声明的意思是：`c_style_function` 这个函数，它的链接属性要按照 C 的方式来处理。这意味着，在生成的目标文件或库中，它的符号名将是 `c_style_function`（或平台相关的简单前缀，如 `_c_style_function`），而不是 C++ 修饰过的 `_Z15c_style_functioni` 之类的名字。
为什么需要这样做？
因为 C 和 C++ 的目标文件在链接时需要能够互相识别。如果 C++ 代码想要暴露一个函数给 C 代码调用，那么 C 代码中的链接器就必须能够找到那个没有经过 C++ 名称修饰的符号。反之亦然，如果 C 代码想要调用一个 C++ 库中的函数，并且该函数是按照 C 接口暴露的，那么 C++ 编译器就需要在该函数上标记 `extern "C"`。
3. `extern "C"` 块内的 C++ 特性：独立于名称修饰
关键在于，`extern "C"` 只影响符号名称的生成方式，它并不禁止你在 `extern "C"` 代码块内部使用 C++ 的特性。
当你写下：
```c++
extern "C" { // 开始一个C linkage块
// 这是一个C++类
class MyCppClass {
public:
MyCppClass(int val) : value(val) {}
void display() {
// 这里的 cout, std::vector 是C++特性
std::cout << "Value: " << value << std::endl;
}
private:
int value;
std::vector data; // STL 容器
};
// 这是一个C++函数，它使用了上面C++类
void use_cpp_class(int v) {
MyCppClass obj(v);
obj.display();
}
// 这是一个使用引用的函数
void process_reference(int& num) {
num = 2;
}
} // 结束C linkage块
```
在这个 `extern "C"` 块内部：
STL (Standard Template Library)： 你可以使用 `std::vector`、`std::cout` 等 STL 库的组件。这些组件在 C++ 的名称修饰规则下，会有自己的修饰名称。
引用 (`&`)： 你可以定义参数为引用的函数，比如 `void process_reference(int& num)`。
类 (`class`)、对象 (`obj`)、成员函数 (`obj.display()`)： 你可以定义和使用 C++ 的类、对象以及调用它们的成员函数。
关键点来了：
1. 内部实现是 C++ 的： `MyCppClass` 的定义、`use_cpp_class` 函数的实现、`process_reference` 函数的实现，这些都是纯粹的 C++ 代码。编译器会按照 C++ 的规则来编译它们，包括为类成员函数进行名称修饰（例如 `MyCppClass::display` 可能会被修饰成类似 `_ZN12MyCppClass7displayEv`）。
2. 暴露接口的名称是 C 的： 但是，当这些 C++ 代码被包装在 `extern "C"` 块中时，编译器被指示：对于这些外部可见的函数符号（比如 `use_cpp_class` 和 `process_reference`），它们在链接层面，应该使用 C 的命名约定。
那么，STL 和引用等 C++ 特性是如何在 `extern "C"` 的 C 链接接口中“工作”的呢？
这不是 `extern "C"` 让 C++ 特性“跑进”了 C 的符号世界，而是说：
被 C 链接的函数内部，可以使用任何 C++ 特性。
但如果你要从 C 代码调用这个函数，你看到的是一个 C 风格的函数名，并且传递的参数也要符合 C 的调用约定（通常是值传递，或者指针传递，但 `extern "C"` 内部的 C++ 函数可以接受引用，因为最终底层的汇编指令会处理引用到指针的转换，而这个转换过程对 C 调用者是透明的，只要函数名是 C 风格的即可）。
举例来说明：
考虑 `process_reference(int& num)` 这个函数。
C++ 编译器内部： 它会生成一个符号，可能类似 `_Z15process_referenceR i`（表示 `process_reference` 函数接受一个 `int&` 类型的参数）。函数体内部，`num` 的使用会被翻译成对传入的指针进行解引用和修改。
`extern "C"` 的作用： 当这个函数被 `extern "C"` 包裹后，编译器承诺，在生成目标文件中，这个函数的外部可见符号名会是 `process_reference`（或者 `_process_reference`）。
C 代码调用： 一个 C 程序调用 `process_reference` 函数时，它会传递一个 `int` 的地址（指针）：
```c
int my_var = 10;
// 调用的是 extern "C" 块中的那个函数，但链接时找到的是名为 "process_reference" 的符号
process_reference(&my_var);
// my_var 现在是 20
```
这里的 `process_reference` 在 C 链接视角下是一个普通的函数，它接受一个 `int `。C++ 编译器在编译 `extern "C"` 块内的 C++ 函数时，会确保它生成的汇编代码能够正确处理传入的指针（对应 C++ 中的引用），并且生成的 C 符号名是正确的。
STL 的情况也类似：
假设 `use_cpp_class` 函数使用 `std::vector`：
```c++
extern "C" {
include // 包含STL头文件
void use_vector(int size) {
std::vector vec(size); // 使用STL
vec.push_back(10);
// ... 其他操作
}
}
```
C++ 编译器内部： `std::vector` 的内部实现，包括它的构造函数、`push_back` 等成员函数，都会被 C++ 编译器按照 C++ 的规则编译和名称修饰。生成的符号可能包含 `std::vector` 的命名空间信息和方法名信息。
`extern "C"` 的作用： 它只影响 `use_vector` 这个顶层函数的外部符号名。生成的符号将是 `use_vector`。
C 代码调用： C 代码调用 `use_vector(5)` 时，它并不知道 `use_vector` 的实现中使用了 `std::vector`。它只是调用一个 C 风格的函数。而 `use_vector` 的 C++ 实现负责正确地实例化、使用 `std::vector`，并最终返回。
总结一下：
`extern "C"` 的作用是隔离 C++ 特有的名称修饰规则，使其在 C 和 C++ 代码的交叉编译和链接时，表现得像一个纯粹的 C 函数或全局变量一样，拥有一个简单且固定的符号名。
它并不限制你在 `extern "C"` 代码块内部编写 C++ 代码的自由度。你可以尽情使用 C++ 的所有特性，包括 STL、引用、类、模板等等。这些 C++ 特性在 C++ 环境下被正确编译和链接。当这些被 C++ 特性支持的 C++ 函数被指定为 `extern "C"` 时，C++ 编译器会确保它们暴露的外部链接符号符合 C 的规范，同时生成的目标代码仍然能够正确地调用和使用内部的 C++ 特性。
你可以这样理解：`extern "C"` 像是一个“翻译官”，它确保 C++ 代码中的某个函数，在与 C 代码交流时，能够使用 C 能听懂的“语言”（即 C 风格的符号名和调用约定），但函数内部的实现细节（包括使用 C++ 特性）由 C++ 本身负责处理，并且这种内部实现对外部的 C 代码是透明的。
为了把这个问题讲清楚，我们需要一步步来剖析：
1. C++ 和 C 的名称修饰（Name Mangling）差异
这是理解 `extern "C"` 关键的基础。
C 语言： C 语言的标准非常简洁，它不进行名称修饰。一个函数或全局变量的符号名就是它在源代码中的名字。例如，一个名为 `my_function` 的函数，在编译后生成的对象文件中，它的符号名就是 `my_function`（可能前面会加上一个下划线，这取决于具体的平台和编译器，但核心是名字本身）。
C++ 语言： C++ 为了支持函数重载（overloading）、命名空间（namespaces）、类成员函数（member functions）等特性，引入了名称修饰（name mangling 或 name decoration）的机制。编译器会将函数的参数类型、const/volatile 等信息编码到函数名中，生成一个唯一的符号名。
函数重载： 如果你有 `void func(int x)` 和 `void func(double y)` 两个函数，C++ 编译器会将它们变成不同的符号，例如 `_Z4funci` 和 `_Z4funcd`（这是一个GCC风格的例子）。这样，在链接时，链接器就能区分并找到正确的函数。
命名空间： 位于不同命名空间下的同名函数也会被区分开。
类成员函数： 类成员函数会被修饰，以包含类名和参数信息。
举个例子：
假设你在 C++ 中有一个函数：
```c++
void greet(int id) {
// ...
}
```
在 C++ 环境下编译，这个 `greet` 函数在对象文件中生成的符号名可能不是 `greet`，而是类似 `_Z5greethi` 这样的。
2. `extern "C"` 的真正作用：控制链接
`extern "C"` 的核心是告诉 C++ 编译器：请为这个函数（或变量）生成 C 语言风格的符号名，而不是 C++ 风格的名称修饰后的符号名。
当你写下：
```c++
extern "C" void c_style_function(int x) {
// ... 这是C++代码
}
```
这句声明的意思是：`c_style_function` 这个函数，它的链接属性要按照 C 的方式来处理。这意味着，在生成的目标文件或库中，它的符号名将是 `c_style_function`（或平台相关的简单前缀，如 `_c_style_function`），而不是 C++ 修饰过的 `_Z15c_style_functioni` 之类的名字。
为什么需要这样做？
因为 C 和 C++ 的目标文件在链接时需要能够互相识别。如果 C++ 代码想要暴露一个函数给 C 代码调用，那么 C 代码中的链接器就必须能够找到那个没有经过 C++ 名称修饰的符号。反之亦然，如果 C 代码想要调用一个 C++ 库中的函数，并且该函数是按照 C 接口暴露的，那么 C++ 编译器就需要在该函数上标记 `extern "C"`。
3. `extern "C"` 块内的 C++ 特性：独立于名称修饰
关键在于，`extern "C"` 只影响符号名称的生成方式，它并不禁止你在 `extern "C"` 代码块内部使用 C++ 的特性。
当你写下：
```c++
extern "C" { // 开始一个C linkage块
// 这是一个C++类
class MyCppClass {
public:
MyCppClass(int val) : value(val) {}
void display() {
// 这里的 cout, std::vector 是C++特性
std::cout << "Value: " << value << std::endl;
}
private:
int value;
std::vector
};
// 这是一个C++函数，它使用了上面C++类
void use_cpp_class(int v) {
MyCppClass obj(v);
obj.display();
}
// 这是一个使用引用的函数
void process_reference(int& num) {
num = 2;
}
} // 结束C linkage块
```
在这个 `extern "C"` 块内部：
STL (Standard Template Library)： 你可以使用 `std::vector`、`std::cout` 等 STL 库的组件。这些组件在 C++ 的名称修饰规则下，会有自己的修饰名称。
引用 (`&`)： 你可以定义参数为引用的函数，比如 `void process_reference(int& num)`。
类 (`class`)、对象 (`obj`)、成员函数 (`obj.display()`)： 你可以定义和使用 C++ 的类、对象以及调用它们的成员函数。
关键点来了：
1. 内部实现是 C++ 的： `MyCppClass` 的定义、`use_cpp_class` 函数的实现、`process_reference` 函数的实现，这些都是纯粹的 C++ 代码。编译器会按照 C++ 的规则来编译它们，包括为类成员函数进行名称修饰（例如 `MyCppClass::display` 可能会被修饰成类似 `_ZN12MyCppClass7displayEv`）。
2. 暴露接口的名称是 C 的： 但是，当这些 C++ 代码被包装在 `extern "C"` 块中时，编译器被指示：对于这些外部可见的函数符号（比如 `use_cpp_class` 和 `process_reference`），它们在链接层面，应该使用 C 的命名约定。
那么，STL 和引用等 C++ 特性是如何在 `extern "C"` 的 C 链接接口中“工作”的呢？
这不是 `extern "C"` 让 C++ 特性“跑进”了 C 的符号世界，而是说：
被 C 链接的函数内部，可以使用任何 C++ 特性。
但如果你要从 C 代码调用这个函数，你看到的是一个 C 风格的函数名，并且传递的参数也要符合 C 的调用约定（通常是值传递，或者指针传递，但 `extern "C"` 内部的 C++ 函数可以接受引用，因为最终底层的汇编指令会处理引用到指针的转换，而这个转换过程对 C 调用者是透明的，只要函数名是 C 风格的即可）。
举例来说明：
考虑 `process_reference(int& num)` 这个函数。
C++ 编译器内部： 它会生成一个符号，可能类似 `_Z15process_referenceR i`（表示 `process_reference` 函数接受一个 `int&` 类型的参数）。函数体内部，`num` 的使用会被翻译成对传入的指针进行解引用和修改。
`extern "C"` 的作用： 当这个函数被 `extern "C"` 包裹后，编译器承诺，在生成目标文件中，这个函数的外部可见符号名会是 `process_reference`（或者 `_process_reference`）。
C 代码调用： 一个 C 程序调用 `process_reference` 函数时，它会传递一个 `int` 的地址（指针）：
```c
int my_var = 10;
// 调用的是 extern "C" 块中的那个函数，但链接时找到的是名为 "process_reference" 的符号
process_reference(&my_var);
// my_var 现在是 20
```
这里的 `process_reference` 在 C 链接视角下是一个普通的函数，它接受一个 `int `。C++ 编译器在编译 `extern "C"` 块内的 C++ 函数时，会确保它生成的汇编代码能够正确处理传入的指针（对应 C++ 中的引用），并且生成的 C 符号名是正确的。
STL 的情况也类似：
假设 `use_cpp_class` 函数使用 `std::vector`：
```c++
extern "C" {
include
void use_vector(int size) {
std::vector
vec.push_back(10);
// ... 其他操作
}
}
```
C++ 编译器内部： `std::vector` 的内部实现，包括它的构造函数、`push_back` 等成员函数，都会被 C++ 编译器按照 C++ 的规则编译和名称修饰。生成的符号可能包含 `std::vector` 的命名空间信息和方法名信息。
`extern "C"` 的作用： 它只影响 `use_vector` 这个顶层函数的外部符号名。生成的符号将是 `use_vector`。
C 代码调用： C 代码调用 `use_vector(5)` 时，它并不知道 `use_vector` 的实现中使用了 `std::vector`。它只是调用一个 C 风格的函数。而 `use_vector` 的 C++ 实现负责正确地实例化、使用 `std::vector`，并最终返回。
总结一下：
`extern "C"` 的作用是隔离 C++ 特有的名称修饰规则，使其在 C 和 C++ 代码的交叉编译和链接时，表现得像一个纯粹的 C 函数或全局变量一样，拥有一个简单且固定的符号名。
它并不限制你在 `extern "C"` 代码块内部编写 C++ 代码的自由度。你可以尽情使用 C++ 的所有特性，包括 STL、引用、类、模板等等。这些 C++ 特性在 C++ 环境下被正确编译和链接。当这些被 C++ 特性支持的 C++ 函数被指定为 `extern "C"` 时，C++ 编译器会确保它们暴露的外部链接符号符合 C 的规范，同时生成的目标代码仍然能够正确地调用和使用内部的 C++ 特性。
你可以这样理解：`extern "C"` 像是一个“翻译官”，它确保 C++ 代码中的某个函数，在与 C 代码交流时，能够使用 C 能听懂的“语言”（即 C 风格的符号名和调用约定），但函数内部的实现细节（包括使用 C++ 特性）由 C++ 本身负责处理，并且这种内部实现对外部的 C 代码是透明的。
网友意见
extern "C" 只是告诉编译器，把这段代码编译成 C 语言可以调用的，而不是说里面只能用 C 的特性。
类似的话题
-
你提出的这个问题很有意思，涉及到 C++ 和 C 之间的接口以及 `extern "C"` 的作用。简单来说，`extern "C"` 的核心功能是指示编译器在进行名称修饰（name mangling）时，遵循 C 语言的规则，而不是 C++ 的规则。它本身并不限制你在 C++ 代码块中使用的语言特............. -
C++ 的开源库之所以看起来“头大”，这是一个非常普遍的感受，尤其对于初学者而言。这背后有多方面的原因，涉及 C++ 语言本身的特性、开源社区的协作方式以及库的设计哲学。下面我将尽量详细地阐述这些原因： 1. C++ 语言的复杂性与灵活性这是最根本的原因。C++ 作为一门多范式语言，提供了极高的灵活.............
-
在C的.NET库中，确实没有一个名为“PriorityQueue”的顶级、开箱即用的通用容器类型，这与某些其他语言或编程模型（如Python的`heapq`模块，或者Java的`PriorityQueue`类）的默认设置有所不同。究其原因，这背后涉及到对“优先队列”概念的理解、.NET设计哲学的取舍.............
-
C++ 中 `main` 函数末尾不写 `return 0;` 为什么会让人觉得不对劲？我们经常会在 C++ 教程或者别人的代码里看到 `main` 函数的结尾有那么一行 `return 0;`。有时候，我们也会看到一些代码里，`main` 函数的结尾什么都没有，直接就结束了。这两种情况，到底有什么.............
-
您提出的问题非常棒，触及了 C++ 社区中一个长期存在且略带争议的话题：为什么那么多 C++ 开源库选择自己实现或包装 `std::string`，而不是直接使用标准库提供的 `std::string`？首先，我们需要明确一点：并非“大多数” C++ 开源库都选择“自己实现 string”。 这是一.............
-
这个问题问得很有意思，也很直接。确实，很多学习过其他编程语言的人，特别是那些熟悉Python、JavaScript或者Java的开发者，在接触C/C++时，常常会有一个疑问：为什么C/C++的函数命名习惯似乎和普遍推崇的“驼峰命名法”不太一样？首先，我们得承认一点：“驼峰命名法”（Camel Cas.............
-
你这个问题挺有意思的，因为实际上，只要你稍微深入地搜索一下，就会发现网上关于C的资源简直是海量，多到你可能都不知道从何下手。说它“少”，这可能是一种错觉，或者是你寻找资源的方式没有完全对准C的生态环境。首先，要理解C的定位。它是由微软主导开发的一种非常现代、功能强大且用途广泛的面向对象编程语言。这意.............
-
提到 C，很多人脑海里可能浮现的是 Windows 桌面应用、Unity 游戏开发，甚至是 ASP.NET Web 服务。然而，如果放眼整个软件开发领域，特别是那些追求极致效率、跨平台能力、或者对底层控制要求极高的场景，C 的身影确实不如某些语言那么“泛滥”。为什么会出现这种“冷热不均”的局面？这并.............
-
大学里 C 语言的教学比 C++ 更普遍，这背后有多方面的原因，而且这些原因并非独立存在，而是相互作用，共同塑造了当前高校的教学格局。要理解这一点，我们需要深入探讨 C 语言本身的特性、它的历史地位，以及 C++ 语言的复杂性，还有教学资源和师资力量等实际因素。首先，C 语言作为一门“母语”般的存在.............
-
在C++开发中，我们习惯将函数的声明放在头文件里，而函数的定义放在源文件里。而对于一个包含函数声明的头文件，将其包含在定义该函数的源文件（也就是实现文件）中，这似乎有点多此一举。但实际上，这么做是出于非常重要的考虑，它不仅有助于代码的清晰和组织，更能避免不少潜在的麻烦。咱们先从根本上说起。C++的编.............
-
C/.NET 在国内的人气远不如国外，这是一个复杂的问题，涉及到技术、市场、生态、历史、文化等多个层面。虽然近年 C/.NET在国内的市场份额有所增长，但与一些本土技术或者其他国际流行技术相比，其普及度和社区活跃度确实存在一定的差距。以下我将从多个角度详细分析 C/.NET 在国内人气不如国外的原因.............
-
C++ 之所以拥有一些“奇特”的语法，背后是一段漫长而复杂的演进史，以及它试图在不同目标之间取得平衡的努力。要理解这些，我们得回到它的起点，然后一步步审视它如何发展至今。首先，要明白一点，很多 C++ 的“奇特”之处，其实是在模仿 C 的基础上，为引入面向对象和更高级的抽象而产生的“妥协”或者说是“.............
-
这个问题触及了 C MVC5 和 JSON 序列化深处的一些历史遗留和设计选择。如果你在 MVC5 中遇到 `DateTime` 属性被序列化成 `/Date(1430366400000)/` 这种格式，这背后并非偶然，而是 ASP.NET Web API（MVC5 主要依赖其进行 API 开发）早.............
-
这个问题很有意思，涉及到 C++ 和 C 在类型定义和内存模型上的根本性差异。简单来说，C++ 的限制是为了保证类型的大小在编译时是确定的，而 C 的灵活性则来自于它对引用类型的处理方式。我们先从 C++ 的角度来看。在 C++ 中，当你定义一个类时，编译器需要知道这个类在内存中占据多大的空间。这个.............
-
你这个问题问得很有意思，涉及到C语言中一个基础但又有点“魔性”的特性：布尔值（Boolean Value）的表示方式。在咱们日常生活中，很多事情都是非黑即白的，比如“对”和“错”，“有”和“无”。计算机世界里也需要这种简单的二元判断。但问题来了，计算机本身只懂0和1，这两个数字如何承载“真”和“假”.............
-
你觉得用C++写出来的游戏简陋，这其实是一个非常普遍且值得深入探讨的问题。很多人刚开始接触游戏开发，尤其是用C++这样一门功能强大但同时也相对底层、门槛较高的语言时，很容易陷入“简陋”的怪圈。这背后有很多原因，我们可以从几个关键点来聊聊。首先，C++本身的学习曲线就相当陡峭。 它不是一门“开箱即用”.............
-
ObjectiveC 的函数名确实有时候会让人觉得冗长，这并非偶然，而是其设计哲学和历史沿革的必然结果。要想理解这一点，我们得深入了解 ObjectiveC 的一些核心特质。首先，ObjectiveC 是一门非常强调消息传递（Message Passing）的面向对象语言。与许多其他语言通过方法调用.............
-
这其中的原因，得从C语言如何理解和处理数字常量的基本规则说起。在C语言里，编译器在解析代码时，需要区分不同的数据类型，以便在内存中为它们分配合适的空间，并知道如何对它们进行操作。对于整数常量，编译器有一套清晰的“签名”来识别它们的类型。当你写下一个纯数字序列，比如 `123`，编译器会默认它是一个十.............
-
梅西和C罗的球迷之间之所以会互相“黑”对方，这背后其实是一系列复杂因素交织的结果，与其说是一种简单的“仇恨”，不如说是一种由体育竞技、个人崇拜、社交媒体放大以及群体心理共同作用下的“爱之深责之切”式对抗。下面我将从几个方面详细道来，力求将这件事讲透彻，也希望你能从中看到一些人情味，而不是冰冷的机器分.............
-
在 C++ 标准库的 `std::string` 类设计之初，确实没有提供一个直接的 `split` 函数。这与其他一些高级语言（如 Python、Java）中普遍存在的 `split` 方法有所不同。要理解为什么会这样，我们需要深入探究 C++ 的设计哲学、标准库的演进过程以及当时的开发环境和需求.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有