您今天是否将C用于软件项目？[关闭]

如果是，您将在何处以及为何使用它？

如果否，请说明为什么您不接受C。

C是系统编程的绝佳语言

如果实现了一些硬件驱动程序，我将使用C。如果实现自己的操作系统内核或虚拟机，我将使用C。

如果您必须处理Windows API，Linux，Mac OS X，Solaris等的硬件或低级OS API，这是做低级事情的一种很好的语言。嵌入式系统通常对C具有良好的支持。与编译器+开发套件。

当然是。我将使用C来编写对性能至关重要的系统或低级通信部件。例如，我会使用C语言在Erlang项目中编写NIF，只是因为它是用于此类工作的The Right Tool（tm）。或者，我将使用C在Perl项目中编写类似的零件（XS）。

我几乎每天都在专业地使用C。实际上，C是我经常编程的最高级语言。

在使用C的地方：我编写了要求尽可能高效的低级库代码。我的粘合代码是用C编写的，内部计算循环是用汇编编写的。

我为什么使用C：处理复杂的参数结构和错误条件要比在汇编中简单得多，并且开始实际计算之前进行这种条件检查的性能开销通常可以忽略不计。因为C是一种简单且经过良好指定的语言，所以每当我看到编译后的代码具有不可接受的性能危害时，我就会很轻松地与编译器团队一起工作，以改善代码的生成。

可移植性是C的另一大优点。我的粘合代码在我正在使用的库的多个特定于硬件的实现中共享，这确实简化了对新平台的支持。大多数平台都没有虚拟机或解释器来显示当月的语言风格。某些平台没有好的C ++编译器。很少有平台缺少可用的C编译器（并且，由于我与我们的编译器团队有着良好的合作关系，因此我通常不会很难获得所需的支持）。

是的，我将在资源严重受限的嵌入式系统中使用C。我可以改用C ++，因为它可以轻松促进软件组件之间的牢固接口，但是只有当所有从事该项目的工程师都知道C ++容易被滥用时，才导致代码大小膨胀（虚函数和模板是应避免的事情的示例） ）。

我还看到一个C ++程序员试图在1K堆栈上创建10K对象，这不是一个好主意。

我主要使用Xen虚拟机管理程序，它具有的各种库和Linux内核。有时，我必须编写一个设备驱动程序（或重新编写一个驱动程序，以便nxx虚拟机可以共享一个设备，例如HRNG）。C是我的主要语言，对此我感到非常满意。

我会尝试使用它编写电子表格程序吗？没门。每个工具都有其应用程序，我很高兴有很多工具。

我爱C，但我不会尝试用锤子敲打螺丝。

如果C是新项目的明智选择，那么可以肯定。如果没有，我会使用其他东西。

我会为一些项目。如果我必须实现一个嵌入式系统，比如说自动驾驶飞机的控制器，那肯定会。组装后某些零件甚至可能下降到更低的高度。

如果它适合项目，我对此没有问题。

如果您想开发一个Web应用程序，可能不行（或者，我需要查看一个非常有力的事实支持的理由）。

当已经清楚地识别出瓶颈并且可以使用本机代码实现优化时，我还将在主要使用其他语言开发的其他项目中使用它。例如，对于一些高级渲染（例如，渲染引擎等），需要执行密集计算的Java解决方案。如果它不是受支持的平台，则可以默认为Java实现，但是可以为某些受支持的平台从C提供本机编译的实现，并获得不错的性能提升。

那里的每种语言都有不错的使用环境。我经常发现自己是用高级语言实现的，然后如果需要高性能或什至只是更便携的话，就逐渐将它们带入C语言。几乎所有的东西都有C编译器，如果您编写通用的API（例如POSIX），那么它可能会非常有用。

我经常告诉那些今天对学习编程感兴趣的人，以确保他们在某个时候学习C并适应它。您可能会发现自己处于需要的环境中。在不止一次的情况下，我不得不编译一个很小的，静态链接的“快速重启”程序，并使用scp将其放在服务器上的RAM磁盘上，磁盘子系统完全消失了。（便宜，便宜的服务器，没有在线冗余，只有加载小程序的能力？C是解决之道。）

同样，学习如何在C中工作而不用shooting脚，可以极大地提高自己用其他语言和环境进行写作的能力。至少，这是我的经验。

虽然我当然不会将它用于所有事物，甚至不是大多数事物，但它具有它的位置并且非常通用：所以，是的，我过去使用过它，将来会使用它（尽管我不会知道此刻的时间）。

是的，我一直都这样做。

如果您不调用任何库，则从C生成的代码不需要操作系统支持。它还使您可以更好地控制生成的机器语言。因此，这对于编写驻留在内核空间中的驱动程序或其他代码以及其他受约束的情况（如多种嵌入式系统）的工作非常有用。它也是我使用的开源项目（如X Windows，GTK +和Clutter）的主要语言。

尽管您可以用C来做所有事情，但是可以用C ++来做，但是通常C ++的机制使编写代码更快捷，更容易。我喜欢OOP和C ++类封装功能的方式，也喜欢RAII。当对象超出范围时，谨慎使用自动析构函数调用可消除大多数内存和资源泄漏，这是C编程的祸根。STL基本上是一个高度优化的算法和数据结构的庞大库；如果要从C使用它们，则必须自己编写或在某个地方购买。

不幸的是，出于我不了解的原因，Linux上的运行时系统需要一个特殊的共享库（相当于Windows上的DLL，相当于Mac上的dylib）来运行任何C ++，并且在运行C程序时找不到。因此，我无法做我最喜欢的Mac和Windows技巧之一，那就是使用基于C的API编写基于C ++的共享对象，然后从C程序中调用它。

所以这是我的决策过程：

1. 我是否在设备驱动程序这样的受限情况下工作？使用C。
2. 我是否正在编写其他人必须使用的Linux库？使用C。
3. 我是否正在使用已经用C编写的代码？使用C。
4. 我是在编写Mac或Windows库，还是仅在使用Linux库？用C ++编写内部结构，但仅公开C接口，以避免出现脆弱的二进制接口问题。
5. 使用C ++。

一件好事是，因为C ++可以编译C，所以如果您真的需要对针对特定情况生成的代码进行细粒度的控制，则可以为此编写C，然后为其余部分编写C ++，然后使用C ++编译器进行全部编译。

是的，但是取决于项目。C对于某些低级项目或最大解决方案的一部分非常有用。

例如。对于商务逻辑正常，但不适用于用户界面。

如果必须两者都

• 快速，并且
• 随身携带

然后我使用C。也许是C ++。

是的，实际上我最近有！

我喜欢用C编程。我大多数时候都用python进行编程，但是有时候我需要快速的代码，并且我真的很喜欢这种语言的简单性带来的优雅。

我现在正在处理的项目是一个数据库，您可以想象，它对性能至关重要。目前，我正在使用C和一些python，但是最终，如果不是全部使用C，它将最终成为主流。

是!

C是一种低级语言，在某些情况下C几乎是唯一的选择，例如我使用C来对微控制器进行编程，或者将一些代码放在一起以与经典端口（例如并行，串行甚至调制解调器）的设备进行交互！

是。我一生的大部分时间都在用C ++进行编程，但是现在我用Ruby编写了大部分代码，如果我需要性能或访问低级内容，可以编写C扩展。这是未来的男人！

如果我正在编写操作系统，则将使用C。由于在接下来的20年中不会发生这种情况，除非我乐透了并且除了做自己的出色Linux发行版之外别无其他事情，我可能只会坚持使用C＃，Java，Python等。很长一段时间没有使用C，但是我一直很喜欢使用它。但是我认为，这些天我的头是如此地缠在面向对象上，如果我不得不回到它上面，那将需要我花些时间重新滚动。

C ++可跨平台和嵌入式设备（如微控制器）移植。（C ++可以编译成C，因此可以编译成微控制器。）

C甚至可以移植（作为外来功能）到其他语言。因此，如果我编写低级库，那么我想要的兼容性比C ++更多。

Haskell可跨平台移植（ARM即将推出），但不能像微控制器那样嵌入设备。它的速度可与C和C ++相提并论。但是因为它是功能性的，所以它使用垃圾收集器而不是运行时堆栈，因此在不同的时间（垃圾收集）和不同的情况（连续而不是子例程调用）下，它可以比C更快，更慢。

我选择了最抽象的语言，因为程序速度没有差异，但开发时间和错误率却没有差异。C和C ++的区别很大，但是从Haskell的角度来看并没有太大区别。

我不喜欢其他语言，即使我会一两手。…除了少数情况，bash。

嵌入式系统通常具有不超过几千字节的RAM和大约几十千字节的闪存，处理器时钟频率为几兆赫兹。在这种裸机环境中，C是唯一有意义的选项。