是否有任何理由使用C ++代替C，Perl，Python等？ [关闭]

#1 楼

当我要表演时，第一个和最后一个选择是C。


这就是应该备份的地方。现在，我根本不能说服务器开发。也许确实没有令人信服的理由偏向于C ++，而不是其他选择。

但是总的来说，使用C ++而不是其他语言的原因确实是性能。这样做的原因是C ++提供了一种抽象方法，与我所知道的所有其他语言不同，C ++在运行时没有性能开销。级别。

考虑通常的抽象：虚函数，函数指针和PIMPL习惯用法。所有这些都依赖于在运行时由指针算法解决的间接。换句话说，这会产生性能成本（但是可能很小）。另一方面，C ++提供了一种间接机制，不会产生（性能）成本：模板。 （这种优势是通过（有时会大大增加）编译时间来弥补的。）

考虑通用排序函数的示例。

在C语言中，函数qsort占用一个函数指针，用于实现元素相对于彼此排序的逻辑。 Java的Arrays.sort函数有多种变体。其中之一对任意对象进行排序，并要求将Comparator对象传递给它，该对象的工作原理与C语言中的qsort中的函数指针相似。但是“本地” Java类型还有更多重载。而且它们每个人都有自己的sort方法副本–可怕的代码重复。 br />在C ++中，sort函数的工作原理与C语言中的qsort相似，但有一个小但基本的区别：传递给该函数的比较器是模板参数。这意味着它的调用可以被内联。比较两个对象不需要间接调用。在一个紧密的循环中（实际上就是这种情况），这实际上可以产生很大的不同。当实际的比较逻辑比较便宜时，这一点尤其明显。 。它提供的是一种既很高又非常便宜的抽象，因此您通常不需要在高效和可重用的代码之间进行选择。

#2 楼

我看到太多讨厌C ++的C程序员。我花了相当长的时间（几年）才慢慢了解它的优点和缺点。我认为最好的表达方式是：

更少的代码，没有运行时开销，更安全。我们编写的代码越少越好。在所有追求卓越的工程师中，这一点很快就变得显而易见。您只在一个地方修复了一个错误，却没有很多，您只表达了一次算法，然后在许多地方重复使用，等等。你对此很明智”。事实的事实是，正确使用C ++，您可以用比C更少的代码来表达自己，而又不花费运行时间，同时比C更安全（即在编译时捕获更多错误）。 br />
这是我的渲染器的一个简化示例：在三角形的扫描线上插入像素值时。我必须从X坐标x1开始并到达X坐标x2（从三角形的左侧到右侧）。在每个步骤中，在我经过的每个像素上，我都必须插值。

当我插值到达像素的环境光时：


当我对颜色进行插值时（称为“ Gouraud”底纹，其中“红色”，“绿色”和“蓝色”字段通过每个像素的步长值进行插值）：

  typedef struct tagPixelDataAmbient {
      int x;
      float ambientLight;
  } PixelDataAmbient;

  ...
  // inner loop
  currentPixel.ambientLight += dv;

当我在“ Phong”阴影中渲染时，我不再插值强度（ambientLight）或颜色（红色/绿色/蓝色）-我插值法线矢量（nx，ny，nz）并在每一步中，我都必须根据插值法向矢量重新计算照明方程：

现在，C程序员的第一个本能是“ h ，编写三个插值的函数，然后根据设置的模式调用它们。”
首先，这意味着我遇到类型问题-我该如何处理？我的像素PixelDataAmbient吗？ PixelDataGouraud？ PixelDataPhong？哦，等等，高效的C程序员说，使用联合！

  typedef struct tagPixelDataGouraud {
      int x;
      float red;
      float green;
      float blue;  // The RGB color interpolated per pixel
  } PixelDataGouraud;

  ...
  // inner loop
  currentPixel.red += dred;
  currentPixel.green += dgreen;
  currentPixel.blue += dblue;

..然后，您就有了一个函数...

  typedef struct tagPixelDataPhong {
      int x;
      float nX;
      float nY;
      float nZ; // The normal vector interpolated per pixel
  } PixelDataPhong;

  ...
  // inner loop
  currentPixel.nX += dx;
  currentPixel.nY += dy;
  currentPixel.nZ += dz;

您是否感到混乱了？

首先，崩溃我的代码只需要一个错字，因为编译器永远不会阻止我函数的“ Gouraud”部分，以实际访问“ .a”。 （环境）值。没有被C类型系统捕获（即在编译期间）的错误，意味着该错误会在运行时显现出来，并且需要进行调试。您是否注意到我在计算“ dgreen”时正在访问left.a.green？编译器肯定没有告诉您。 ”。丑陋且容易出错。当我应该使用“ j”时，您是否注意到我在Gouraud循环中使用“ i”进行了比较？编译器再次处于静默状态。

模式的if / else /阶梯怎么样？如果我在三周内添加了新的渲染模式怎么办？我会记得在我所有的代码中都使用“ if mode ==“”来处理新模式吗？ >

  typedef union tagSuperPixel {
      PixelDataAmbient a;
      PixelDataGouraud g;
      PixelDataPhong   p;
  } SuperPixel;

现在看看这个。我们不再制作联合类型汤：每个模式都有特定的类型。他们通过从基类（for）继承来重用其常用的东西（“ x”字段）。模板使编译器创建（即代码生成）我们将用C编写的三个不同函数，但同时要严格限制类型！

我们的循环模板中的内容无法执行操作并无法访问无效字段-如果这样做，编译器将吠叫。模板执行共同的工作（循环，每次都以“步长”递增），并且可以以不会导致运行时错误的方式进行。每个类型（CommonPixelData，AmbientPixelData，GouraudPixelData）的插值都是通过我们将在结构中添加的PhongPixelData完成的-基本上规定了每种类型的插值方式。 ？我们要为每种类型做不同的工作？我们只需调用模板专用化即可：

  RasterizeTriangleScanline(
      enum mode, // { ambient, gouraud, phong }
      SuperPixel left,
      SuperPixel right)
  {
      int i,j;
      if (mode == ambient) {
          // handle pixels as ambient...
          int steps = right.a.x - left.a.x;
          float dv = (right.a.ambientLight - left.a.ambientLight)/steps;
          float currentIntensity = left.a.ambientLight;
          for (i=left.a.x; i<right.a.x; i++) {
              WorkOnPixelAmbient(i, dv);
              currentIntensity+=dv;
          }
      } else if (mode == gouraud) {
          // handle pixels as gouraud...
          int steps = right.g.x - left.g.x;
          float dred = (right.g.red - left.g.red)/steps;
          float dgreen = (right.g.green - left.a.green)/steps;
          float dblue = (right.g.blue - left.g.blue)/steps;
          float currentRed = left.g.red;
          float currentGreen = left.g.green;
          float currentBlue = left.g.blue;
          for (j=left.g.x; i<right.g.x; j++) {
              WorkOnPixelGouraud(j, currentRed, currentBlue, currentGreen);
              currentRed+=dred;
              currentGreen+=dgreen;
              currentBlue+=dblue;
          }
...

即-调用的函数取决于类型。在编译时！

再次重述一下：


我们通过重复使用通用部分来最小化代码（通过模板），
我们不使用丑陋的hack，我们使用严格的类型系统，以便编译器可以随时检查我们。该代码的运行速度几乎与等效的C代码一样快-实际上，如果C代码使用函数指针调用各种operator+=()版本，则C ++代码将比C更快，因为编译器将内联特定于类型的WorkOnPixel模板专业化调用！

代码更少，运行时没有开销，更安全。当然不是。您仍然必须权衡取舍。无知的人应该在编写Bash / Perl / Python脚本时使用C ++。满足触发器要求的C ++新手将创建具有虚拟多重继承的深层嵌套类，然后才能停止它们并将其打包。在意识到这是不必要的之前，他们将使用复杂的Boost元编程。他们将仍然使用WorkOnPixel，char*和宏，而不是strcmp和模板。没有语言能使您免受能​​力不强的用户的侵害（没有，甚至没有Java）。

继续学习和使用C ++-只是不要过度设计。

评论

---

+1表示“不，甚至不是Java” ：）

–内森·奥斯曼（Nathan Osman）
2010-12-27 5:32

---

范例为+1。这是一篇很长的文章，但是C和C ++代码之间的比较令人印象深刻。

–paercebal
2011年5月29日13:17

---

女士们，先生们，这就是为什么lex / yacc存在的原因。同样的道理，我从未意识到c ++的某些部分会陷入相同的代码生成哲学。我将不得不再次查看它。

– Spencer Rathbun
2012-09-28 18:41

---

我已经写了很多2D渲染代码（十多年前），并且在从C移植到C ++时遇到了这个问题：如果您的扫描线是由1位像素（8个像素，一个字节）？当扫描线由R，G和B字节（每个像素3字节）组成时？当您有三个分别用于R，G和B的缓冲区时？您知道答案：C ++在那里无济于事，坚持使用模板将使您失去很多空间和时间优化

–沃尔特·特罗斯（Walter Tross）
13-10-29在0:39

---

为什么为此使用C ++中的模板？您的方法声明了基类的参数，因此从我的[C＃程序员]的角度来看，您似乎可以将派生类型实例传递给基类型参数。我不懂C ++，您能解释一下吗？

– Vlad
16-3-13在14:42

---

#3 楼

用RAII赢取宝贝。

认真地讲，C ++中的确定性销毁使代码更清晰，更安全，而没有任何开销。

#4 楼

使用C ++是否有令人满意的理由？



模板和STL。您只需花费很少的构建时间（以及一些可能难以理解的错误消息）就可以使用许多有用的抽象和省力的工具，而不会对运行时性能造成明显的影响（尽管二进制足迹可能会更大）。将头缠起来需要一段时间（单击之前花了我几年时间），但是一旦这样做，它会使生活变得简单很多。比C语言减轻了几个数量级的痛苦。

#5 楼

是的。

如果您要寻找可执行的效率，那么您会使用C或C ++，因此我将重点关注它。

即使在模板通用之前，早在1990年代中期，我就比较喜欢使用C ++来处理各种可执行文件，这有两个很简单的原因：对象多态性和RAII。

我将多态C ++对象用于各种有趣的事情东西。例如，我正在一个嵌入式Linux系统上工作，该系统在OMAP和XScale ARM CPU上具有帧缓冲区覆盖。两种硬件体系结构具有不同的覆盖功能，并且具有非常不同的API。我使用一个通用的虚拟“ Overlay”基类公开了理想的叠加视图，然后编写了“ OmapOverlay”和“ XScaleOverlay”类，这些类在运行时进行了适当实例化，具体取决于在其上运行代码的架构。 />
为了简化起见，RAII的想法是在对象的构造函数期间或对象生命周期的稍后阶段分配连接到对象的资源，然后在对象的析构函数中释放资源或释放资源。在C ++中，这确实很棒，因为自动变量的对象在超出范围时会被破坏。对于同时具备C和C ++能力的人，避免C ++中的资源和内存泄漏要容易得多。您还看不到太多的C ++代码，在函数的末尾，在对free()的大量调用之前，以及在函数块中跳跃的各种goto之前，在标签的末尾都没有非常常见的C符号。

我完全意识到，您可以使用C来完成所有这些事情-它要做的工作很多，方式更多，代码行很多，而且最终得出的结果更加丑陋，而且通常很难理解。 X服务器内部遍历了多态性代码，伙计，它是丑陋又怪异的，而且经常很难追踪。

我还使用GTK +和Clutter等GNOME技术进行了大量工作，所有这些技术都是使用GObject系统以C语言编写的。 GObject就像C ++对象系统一样，它的封面很漂亮，所有丑陋的内部结构都暴露在外，它通常需要六行代码来完成单行C ++方法调用所要做的工作。我目前正在写一些ClutterActors，虽然数学真的很有趣，但我一直在想：“在C ++中，这一切将更加简洁和易于理解。”

我也经常想， “你知道，如果我是用C ++而不是C编写的，那么我会和妻子在客厅里看着MythBuster，而不是晚上9点坐在办公室里。”

#6 楼

C ++的速度与C差不多（有些东西更快，有些慢），并且它提供了更好的抽象性和组织性。类的工作方式与原始类型相似，从而无需记住即可使用大量代码。运算符重载和模板使编写代码的功能变得可能，如果数据表示形式发生变化，代码的功能会更好。异常可以简化错误处理。编译器可用于在编译时检查更多内容。

为此付出的代价是一个相当讨厌的学习曲线，并且比我使用的其他大多数语言更容易犯一些细微的错误。我很熟悉。

所以，我不能告诉您现在进行的学习是否值得。当然可以将Python或Perl与C结合使用，但是C ++在一个难以使用的软件包中提供了抽象和性能。

#7 楼

我认为C ++是1990年代的一种语言，是一种过去的语言。

当时它之所以大，是因为它以较低的性能成本提供了高级语言结构和机制。它是开发从通讯录应用程序到航空电子软件的一切工具的通用工具，这激发了OO狂潮。 OOP解决了饥饿和艾滋病，是的，我责怪C ++在1990年代末试图洗脑时，我第一次开始编程，任何非OO语言都不值得学习。
如此先进和更新的现代语言已经出现，我看不到C ++仍然是大多数应用程序编程的相关选择，除了需要大量抽象（游戏，物理模拟，CAD系统等）的计算密集型软件。如果您使用C语言编写紧凑的模块化引擎，并将高级应用程序逻辑委派给一种简洁的脚本语言，则甚至可以避免后者。 ，并且当您需要进行高级学习时，可以使用一种现代的语言来完成封装，而您可以通过指针自由地更改每个字节。

#8 楼

根据Linus的说法，不是：





当我第一次查看Git源代码时，有两件事使我感到奇怪：
1.纯C而不是C ++。不知道为什么。请不要谈论可移植性，它是BS。


你胡说八道。由于很多
不合格的程序员使用它，使它变得更加可怕，以至于
更容易产生总的和完全的废话。坦白说，
即使选择C除了使C ++程序员不做任何事情，
本身就是使用C的巨大理由。

词：选择C是唯一明智的选择。我知道Miles
Bader开玩笑地说“让你生气”，但这是真的。我
得出的结论是，任何喜欢
项目而不是C的C ++程序员都可能是我真的
讨厌的程序员，所以他不会不能搞定我参与的任何项目。

C ++会导致非常糟糕的设计选择。您总是开始使用该语言的“ nice”库功能（例如STL和Boost
）以及其他一些完全废话开始，这可能会“帮助”您编程，但是
会导致：
>

当它们不起作用时会产生无穷的痛苦（而且任何告诉我STL尤其是Boost都是稳定且可移植的人
都充满了BS，甚至都不好笑）
效率低下的抽象编程模型出现了两年，您注意到有些抽象不是很有效，但是
现在您的所有代码都依赖于周围所有漂亮的对象模型，
无法重新编写应用程序就无法修复它。

换句话说，执行良好，高效和系统级的唯一方法
和可移植C ++最终将自己局限于所有事物是
基本上只能在C语言中使用。将项目限制在C语言中意味着
人们不会搞砸它，也意味着您会得到很多真正理解低级问题而又不理解的程序员。 t
用任何愚蠢的“对象模型”废话弄糟。

对不起，但是对于git这样的效率为主要目标的东西，“ C ++的优势”，这是一个巨大的错误。
我们还激怒了那些看不见的人，这只是一个很大的附加优势。

如果您想要VCS用C ++编写的代码，可以玩Monotone。
真的。他们使用“真实数据库”。他们使用“不错的面向对象的
库”。他们使用“不错的C ++抽象”。坦率地说，作为所有这些设计决定的结果，对于某些CS人士来说，它是如此吸引人，最终结果是一个可怕且难以维护的混乱局面。

但是我确保您比git更喜欢它。

      Linus

#9 楼

我认为没有任何令人信服的理由使用C ++。如果要进行OO编程，则可以改用Python并用C编写需要快速性能的部分。像Python一样，还有其他选择。

#10 楼

有理由使用C ++吗？当然。

有些人可能更喜欢使用C ++，而不是其他选择。询问是否有理由使用C ++就像询问为什么我们需要数百种口味的冰淇淋。并非每个人都喜欢简单地坚持使用Vanilla。 SO中似乎正在发生这种流行的反C ++事情，但是不管您是否相信，并非所有人都赞成。有些人可能比其他语言更喜欢C ++。

应用程序需要使用C ++吗？当然不是。但是，对于任何其他语言，也可以询问相同的确切问题。在极少数情况下，需要在应用程序中使用特定语言。

#11 楼

我只是从C切换到C ++，即使您不需要模板和OOP，我也认为收益可观。


更好的内存管理
更强大的类型系统
更好的标准库
命名空间
等。

#12 楼

令我惊讶的是，到目前为止还没有人提到它，但是C ++向我们介绍了引用，它几乎解决了指针的所有问题和陷阱：

br />

void ModifyVar(int& var)
{
    var = 5;
}

int test = 4;
ModifyVar(test);

也更安全，更容易...而且没有传递值的开销。

#13 楼

通常的位置和原因将是：


熟悉
所需的语言功能
要使用的特定库
性能要求

对于服务器端编程，您通常可以选择多种不同的语言进行编译或解释。通常，语言的选择取决于您或您的团队在哪个平台上最有效。或者，如果您还没有团队，那就是市场上技能的可用性。

顺便说一句，我真的不理解基于性能来决定使用C / C ++，因为C / C ++可以扩展许多脚本语言。您将获得快速开发语言的好处以及将慢速部分迁移到C / C ++扩展的能力。当然，如果您在进行系统编程时每个操作都很重要，那是可以理解的，但是在大多数应用程序开发中，我是无法理解的。

#14 楼

C ++ vs Python vs Perl很难判断。这取决于项目和要求。

C ++拥有很久以前的大量实用程序，可在许多平台上运行。但是开始遍历流只是将String传递给Integer并进行反向操作是很痛苦的。另一方面，C ++对库的依赖项处理得很糟糕。一旦在GCC X或VC ++ Y中进行了编译，就无法依靠代码将在这些工具的下一版本中运行。在Windows上同样如此，在Unix上也同样如此。这是大多数时候使用的。除了一些非常严肃的工具，甚至Java都无法以正常方式完成（请查看如何将文件上传到Web服务器），Perl还是“只是做”。简单，灵活和动态的语言。如此简单，您可以将整数发送给函数，脚本需要字符串，但可以得到结果！虽然出乎意料，但却是结果。因此程序员需要非常谨慎。空闲提供了一些调试功能，但是当您将TELNET连接到系统上，或者将SSH降低了三个级别，而您想查找问题时，调试器将不会在那里站着。但是，它可以快速完成一些很棒的数学工作。仅当服务器具有JSP时。
如果要调用系统库或诸如监视之类的系统功能，您会发现需要大量挖掘。也许要达到JNI并确定...然后您想...“为什么，主？”

除此之外，Java是用于商务套件和多线程的出色工具，我喜欢它很多。

快速编写程序并向您的简历显示“哦，我也知道技术”，而您想要成为的老板也很惊讶！即使，可能也不需要该技术...（好吧，伙计们，我讨厌Spring框架...。）

#15 楼

选择语言时要牢记的一点是，使用它会带来什么好处，以及获取它需要花费多长时间。

python和perl等语言之间的主要思想是以更少的人工时间，却以更多的cpu时间来完成更多工作。实际上，您花在编写python或perl脚本上的时间会比执行它们花费的时间多，但您的理解是正确的。语法和强类型化：您必须自己做很多事情，以使计算机不必在编译时选择它。其他的，而那些线就是一个问题。另一方面，其余所有代码（您花了很多时间编写的代码）的执行频率要低得多。
您可能已经听说过，但这是臭名昭著的80/20规则，并且您将无法绕过这样的规则。

解决此问题的方法是使用一种更简单的语言（更容易地说，我的意思是对开发人员更友好：更少的键入，惰性的解释，很多预先存在的语言例程和东西等）来完成所有代码。

与使用C或C ++进行处理相比，您将如此快速地进行处理，这将使您的大脑更加痛苦。 br />
您的程序会很慢，但是使用事件探查器，您可以隔离运行了80％的时间的零件，然后使用C或C ++进行。

通过编程这样，您节省了很多时间，并且程序效率高，速度快，泄漏内存的机会少了很多，而且节省了时间。开发人员方面，但仍可以进行优化。当然，您可以是设计模式的魔术师，STL伏都教徒，甚至是轻率的战士，甚至是Haskell的和尚。但是语言使我们与计算机对话，而语言不是让我们成为计算机！

#16 楼

Linux的？那么“面向对象的Pascal”还是“ D”呢？

建议：


Lazarus
简介-D编程语言2.0-数字火星

#17 楼

我使用的C ++称为带有类的C！

#18 楼

对于这样形成的所有问题，实际上只有一个答案。使用技术X而不是技术Y（其中X和Y大致处于同一水平（就像几乎所有当代编程语言一样））的最佳原因是因为您已经了解X而不了解Y。

（但Haskell到达后，没有理由使用其他任何东西）

#19 楼

一点都不。如果您不需要性能并且有一个库，您可以使用其他语言，那么不必担心C / C ++。如今，我只针对无法（轻松地）运行语言的嵌入式系统这样做。有时我使用C是因为我正在编写一个插件，但实际上不是。

但是，我不会使用Python，Perl等来避免使用C。我的偏好实际上是C＃，因为我喜欢好的库（这是.NET的强项），而且我喜欢静态类型的语言。嘘是个不错的选择。但实际上Haskell，OCaml，D，ML等都很好。