我正在研究内核。编写内核的任务之一是必须移植C库。某些功能（例如memcmp，strlen等）必须重写。大多数时候，我看到用C语言编写的代码，然后包含在extern "C"中。但是，这使我的构建过程变得复杂，因为有很多用C语言编写的文件，以及许多用C ++编写的文件，这些文件必须链接在一起，这只是一个令人头痛的问题。如果整个事情可以用C ++编写，那将是很好的。
这会有意义吗？
答案 0 :(得分：1)
如果该端口仅用于您的内核，那么您可以随心所欲。如果您计划向内核用户提供对该库的访问权限，则接口必须是 C。但是，实现可以是您想要的任何语言。
现在对于大多数函数来说，使用 C++ 函数然后创建 C 函数来访问 C++ 函数没有多大意义，因为函数本身不会使用 C++（至少对于 {{ 1}}，你真的不需要使用 strlen()，你可以用 C 用一个简单的循环重写它）。
您还可以重用 GNU C 库中您需要的函数。即只需将这些功能复制到您的实现中。只需确保保留相同的许可证即可。为了提高速度，该库在各种汇编语言中有许多此类低级函数的实现。例如，std::find() 函数加载 64 位并使用逻辑 (strlen(), NOT, AND...) 确定是否存在 0x00 字节，这使得函数效率极高。
GNU C 库还包括调用内核函数的特殊函数。显然，您不希望直接在您的内核中使用这些（嗯，可能不会，这将取决于您的内核）。
最后，C 库比 XOR 之类的几个函数复杂得多。它必须与数以千计的软件一起工作，所有这些软件都可能链接到略有不同的版本。因此，strlen() 在同一个 C 库中实际上可能有 20 个版本。可能您暂时不想担心（直到您的内核被许多人使用），但这对于您计算机上运行的软件的长期稳定性可能很重要。如果一个软件期望某个函数返回 strlen()（旧版本）而另一个函数返回 EINVAL（新版本），这一点尤其重要。在处理数以千计的软件时，如此微小的差异非常重要。
再说一次，听起来您的意思是在您的内核中具有辅助函数。在 C 库中可用但不是实际 C 库的辅助函数（我认为以这种方式链接内核不是一个好主意）。它应该是特定于您的内核的辅助函数库，您可以静态链接它。实际上，您应该只添加内核使用的函数，仅此而已。
最后，如果您的内核是用 C++ 编写的，那么您的辅助函数也可以用 C++ 编写。但是，如果您计划拥有一些仅使用 C 的小部件，并且其中一些辅助函数将在这些小部件中使用，那么用 C 编写这些辅助函数会更容易。 EIO 显然只在 C 中是必需的，因为在 C++ 中您希望使用函数的 strlen() 成员。