为什么操作系统会在C和C ++中做底层工作？为什么不只是C ++？

在Windows的Wikipedia页面上，它指出Windows是用Assembly语言编写的，用于引导加载程序和任务切换器，以及C 和 C ++语言的内核例程。

IIRC，您可以从extern "C"'d块调用C ++函数。我可以将C用于内核函数，这样纯C应用程序就可以使用它们（诸如此类printf），但是如果它们只能包装在一个extern "C "块中，那么为什么要用C语言编写代码？

这主要是出于历史原因。Windows内核的某些部分最初是用C编写的，因为1983年，即三十多年前，当Windows 1.0发布时，C ++才刚刚发布。现在，这些C库将“永远存在”，因为Microsoft将向后兼容性作为卖点，而用C ++重写与C部分兼容的bug版本则需要付出大量的努力，而没有任何有效的收益。

正如大多数人所指出的，到目前为止，原因是有历史的，但是没有人提及，我相信这就是人们仍然为底层编写C代码的原因。

就规范而言（相对）简短而言，C是一门小语言。C ++非常庞大，这是一种轻描淡写的说法。对于程序员来说，这可能无关紧要（尽管我认为确实如此），但是如果您要进行形式验证，则这非常重要。此外，已经建立了用于C代码分析的工具，可以帮助防止错误等。

对于嵌入式软件而言，这是非常重要的，相对于其他行业，嵌入式软件中部署错误的成本非常高（比较Web，您可以在其中立即将补丁应用于所有用户）。更不用说关键任务软件和医疗产品了。

曾有人试图用低级编程（例如BitC）将C从其在低级编程中的主导地位中移开，但到目前为止还没有成功。

1. C运行时要小得多。
2. 与C语言相比，将C ++转换为低级结构的透明性较差。（有关两个快速示例，请参见参考资料和vtables）
3. C通常具有稳定的ABI。C ++通常不会。这意味着系统调用接口至少应为C样式。另外，如果您需要任何种类的动态模块，那么拥有一致的ABI将会有很大的帮助。

原因不是技术原因。组装一点点是不可避免的，但它们不是强制使用，偶尔C，他们希望到。我公司使用自己的专有内核，几乎完全用C ++编写，但是我们不需要像大多数其他大多数人一样支持到内核的C接口，因为嵌入式内核是用C ++应用程序整体编译的。使用C接口时，即使可以用extern "C"C ++ 编写接口代码，通常也更容易用C编写接口代码。

即使是我们也有一些C文件，这主要是由于第三方代码所致。第三方低级代码几乎总是用C提供的，因为将C代码合并到C ++应用程序中比使用其他方法容易得多。

内核开发人员通常是那种会感到更快乐的人，当从源头上立即看到代码实际上是做什么的时候。

C ++具有更多功能，这些功能比普通的C代码更能隐藏代码：重载，虚方法，模板，引用，抛出... C ++还必须掌握更多的语法才能理解C ++。使用它的代码。

我认为C ++的强大功能非常强大，可以创建库和框架，从而使应用程序开发变得轻而易举。即使C ++应用程序开发人员非常有能力使用该库创建应用程序，但通常情况下，他们都会完全迷失在该库的模板填充内部。正确地编写C ++库权限是一项非常具有挑战性的编程任务，仅是为了为应用程序开发人员的利益提供良好的框架而完成。C ++库在内部并不是简单的，从应用程序程序员的角度来看，它们是（或可以...）功能强大而又简单。

但是内核API不能是C ++ API，它必须是与语言无关的API，因此C ++中的大多数优点都不能在该接口上直接使用。此外，内核并没有真正分为独立开发的“库”和“应用程序”部分，逻辑上需要花费更多的精力到一个库上，以简化大量应用程序的创建。

而且，与纯回调或其他类似C的机制相比，内核内部的安全性和稳定性更为关键，虚拟方法更具动态性，因此更难隔离和验证。

简而言之，尽管您当然可以将包括内核在内的任何C程序编写为C ++，但是C ++的大多数功能在内核中并未得到很好的利用。许多人会认为，编程工具应阻止您执行不应执行的操作。C ++不会。

Bjarne Stroustrup 在1999年7月的一次采访中：

这些语言都没有一个比其他当代语言有根本不同或有显着提高。但是，他们足够好，是运气和社会因素的受益者

从设计的角度来看，C是一种非常底层的语言。距汇编程序仅一步之遥；知道了您要定位的芯片组后，您只需一点知识就可以将C手动“编译”为ASM。这种“最接近金属”的语言对于高水平的优化（性能，内存效率等）至关重要。但是，因为它离金属很近，所以用这种语言您不会免费得到很多。它是一种过程性的，非面向对象的语言，因此使用此类构造涉及大量样板代码来创建和使用内存中的多值构造。

C ++是“更好的C语言”，它添加了许多易于使用的功能，例如动态内存分配，内置结构编组，大量预定义代码库等，但以牺牲一些效率为代价（仍然更好）比托管运行时环境）。对于普通编码器而言，在不需要对内存分配进行肛门保持控制的代码库领域中，其优点远胜于缺点。

两者的结合是很传统的。您可以使用C编写代码库中对性能最关键，内存效率最高的区域，然后可以通过C ++代码中的方法调用以更加抽象的方式使用该区域，该代码可以比超级性能更好地组织和设计。 ，超级优化的C代码。

可能是因为使用C，您将大部分时间花在思考手头的问题以及如何编码解决方案上。在C ++中，您最终会想到C ++及其众多的功能，函数和晦涩的语法。

同样，在许多C ++商店中，您的代码也受到“时尚警察”的监视，他们被最新的设计模式集或伟大的上帝Stroustrup的最新的令人费解的声明所吸引。漂亮的代码变得比工作代码更有价值，与为业务找到可行的解决方案相比，钦佩使用最新的Boost模板集更令人钦佩。

我的经验是，对于C ++的所有聪明功能和OO纯度，纯C语言编码可更快，更有效地完成工作。

C部分可能无法很好地移植到用于C ++部分的C ++编译器中。也许C代码在C编译器方面有点笨拙，而与C ++编译器的关系却不那么理想。

如果您有高质量的C ++编译器，几乎没有理由在项目中混合使用C和C ++。几乎。

一个原因是您的项目与其他项目共享C代码，该代码无法作为C ++编译，并且您不想维护该代码的C ++分支。

我认为您倒向了它-该extern "C"块确保将C调用约定用于该块内的所有函数。因此，您可以从C ++调用纯C函数，而不是从C调用C ++函数。无论如何，我想人们同时使用C和C ++的原因是因为许多低级库都是使用C编写的，因此使用比编写自己的脚本已经存在（可能已调试和优化）。OTOH，C ++提供了许多人们希望使用的出色的高级功能，因此他们将其用于其余部分。

有多种级别的嵌入式平台使用C作为编程语言（当然，您可以随时使用汇编语言）

对于“级别”，我说的是系统的内部SRAM和ROM资源级别。

这些平台有时受到资源限制（例如，某些8051平台仅具有128字节的User SRAM）。

以如此少量的RAM支持动态内存分配是没有意义的。（新建/删除），甚至在C中使用malloc。

从C到C ++的主要改进之一是面向对象的范例。C ++适用于具有更大内存占用量的软件

但不能在大小上限为32KB的嵌入式固件中使用。（例如，在16位MCU平台中）

不需要C ++编译器，它通常比C编译器复杂。（至少SDK提供程序不会这样做）。

实际上，我几乎无法在32位ARM7平台上找到C ++编译器。

只是不值得复杂

在某些8051（8位）中：1MB ROM，128B RAM

TI MSP430（16位）：32KB ROM，4KB RAM

ST Microelectronics ARM 32位Cortex™-M3 CPU内核（STM32F103T4）：16或32 KB闪存6或10 KB SRAM

我看到一些可能的原因：

• 与C ++相比，C的效率更高。
• 他们使用的某些库是用C编写的。
• 他们使用Linux内核的某些部分，这些部分是用C编写的。

编辑：事实证明，第三个参数不正确（请参阅注释）。

因为可以说C是比C ++更好的语言。而且由于某些代码是在C ++流行之前编写的，因此人们没有理由替换它。

而且由于C ++具有许多功能，如果您不小心在内核中使用它，可能会破坏您的代码。