嵌入式Linux中的C vs C++

Gre*_*ich 13 c c++ performance embedded-linux

我正在开发嵌入式Linux(ARM)的应用程序.它将执行500次/秒,因此速度很重要.我更喜欢使用C++,但我担心它会比C慢,即使我避免像虚函数这样的奇特功能.是否有理由使用C或者用C++编写它就好了?

Mar*_*ett 17

一般来说,C++不会因C而受到运行时间的影响 - 除了像RTTI这样的东西之外.

除了在一些奇怪的情况下,编译器应该能够确定在编译时调用哪个虚函数,因此不增加开销.

编辑:好的,有各种各样的编译器,CPU,运行时库,操作系统,有一些C++的功能可能会创建更慢的代码,有些功能可能会创建更快的代码.

但我们是否都同意C++不再被自动排除在嵌入式使用之外?

  • 虚拟功能和模板应该没有成本.如果没有在任何体面的编译器上调用,则异常是零成本.Dynamic_cast通常在没有RTTI的情况下工作 - 只有一些警告.代码大小可能是一个问题 - 但它取决于您对嵌入式课程的意义 (2认同)
  • 如果可以从正常代码流中删除C错误处理,则异常会产生负成本.优化器可以很容易地针对非异常情况进行优化,但是在发生错误时不知道C函数是返回0,1还是-1. (2认同)

j4x*_*j4x 8

在C++中,您可以使用模板元编程等功能,在编译时解决C或任何其他过程编程语言在运行时必须执行的几种情况.

我应该说更多.模板元编程和一些类继承技巧真的很棒.通过"ifing"和"切换",它可以为您节省大量的处理时间.

这意味着如果进行得很好,C++实际上可以比C更快.

显然你可以用C++编写"in C",你根本不会受到任何惩罚.如果你不太喜欢C++,我建议你做一个"C++ C++"或"C with C++扩展"只是为了获得C++改进的优势,但你真正的优势在于编写C++办法.在那里你会看到C++ 很好的一部分,或者比C更快或更干净,或者至少和C一样快.

没有恐惧.面对C++.在stdc ++(针对libc)之后,代码大小几乎没有开销.如果您的申请从中等到高,它将被稀释.

我使用C++从简单的8位ATmega到Marvell的ARM9,通过AVR32 UC3和Cortex-M3,总是觉得它有利可图.

如果您在特定情况下需要特别建议,请随时提出.


Zac*_*and 6

只要限制所使用的功能,与 C 相比,C++ 的性能不会有太大影响(如果有的话)。您需要避免的功能包括:异常、RTTI 以及保持类层次结构尽可能平坦(并谨慎使用虚拟函数)。


Eri*_*rik 6

选择C over C++的主要原因是编译二进制文件的大小,这可能是嵌入式系统的真正限制.

在性能上,如果您使用正确的语言,则没有可衡量的差异.你可以像慢速C++一样轻松地编写慢速C代码,只要你知道你所写的内容的底层机制你应该没问题.

  • 如果C版本在功能上与C++版本等效*,则大小差异可以忽略不计.例如,如果C++版本使用继承,则C版本还必须编写等效的代码,而不是快捷方式.根据我的经验,尺寸不是问题. (6认同)
  • @Thomas:这根本不是真的,因为许多被引入的库代码将具有所需功能的巨大超集,并且链接器无法确定哪些部分可以省略.静态链接C hello world程序与任何理智的C库(任何BSD,uClibc,Bionic等 - 只是不是glibc,其stdio基本上是用C++编写的)并使用iostream比较等效的静态链接C++程序. (3认同)
  • @R ..:如果你选择了一个合适的libc实现,你应该公平地选择一个同样合适的iostream.Dietmar Kuehl已经证明(大约10年前),Hello,World在C++中可以更小.原因很简单:链接器_can_消除`operator << ostream&,float)`而不是来自`printf()`实现的`case'f':`. (2认同)