C vs C++在嵌入式Linux中
我正在开发一个嵌入式 Linux (ARM) 应用程序。它将执行 500 次/秒,因此速度很重要。我更喜欢使用 C++,但即使我避免使用虚函数等花哨的功能,我担心它也会比 C 慢。 是否有使用 C 的理由,或者用 C++ 编写也同样可以?
I am developing an application for embedded Linux (ARM). It will execute 500 times/sec, therefore speed is important. I would prefer to use C++ but I am afraid it will be slower than C even if I avoid fancy features like virtual functions.
Is there a reason to use C or it's just as fine to write in C++?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
一般来说,与 C 相比,C++ 不会遭受运行时间损失(除了 RTTI 之类的一些东西)。
除了在一些奇怪的情况下,编译器应该能够确定在编译时调用哪个虚拟函数,因此不会增加任何开销。
编辑:好的,对于如此多种编译器、CPU、运行时库、操作系统,C++ 的某些功能可能会创建较慢的代码,而有些功能可能会创建更快的代码。
但我们是否都同意 C++ 不再自动排除在嵌入式使用之外?
C++ in general suffers no run time penalty over C - (except for a few things like RTTI).
Except in a few odd circumstances the compiler should be able to determine which virtual function to call at compile time and so add no overhead.
Edit: Ok with such a variety of compilers, CPUs, runtime libs, OSes there are some features of C++ that might create slower code, there are some features that might create faster code.
But can we all agree that C++ isn't automatically excluded from embedded use anymore ?
在 C++ 中,您可以使用模板元编程之类的功能,在编译时解决 C 或任何其他过程编程语言必须在运行时执行的多种情况。
我应该多说一点。模板元编程和一些类继承技巧确实令人惊叹。它可以为您节省大量处理时间,否则您将花费在“ifing”和“switching”上。
这意味着如果执行得当,C++ 实际上可以比 C 更快。
显然,您可以使用 C++ 进行“C 语言”编程,并且不会受到任何惩罚。
如果你不太喜欢 C++,我建议你做“C on C++”或“C with C++ extensions”,只是为了利用 C++ 的改进,但你真正的优势是通过对 C++ 进行编程方式。在那里,您将看到 C++ 在很大程度上比 C 更快或更干净,或者至少与 C 一样快。
不要害怕。面对C++。
在 stdc++(相对于 libc)之后,代码大小几乎没有任何开销。如果您的申请规模从中等到大,它将会被稀释。
我使用C++,从简单的8位ATmega到Marvell的ARM9,经过AVR32 UC3和Cortex-M3,总是发现它有利可图。
如果您在特定情况下需要具体建议,请随时询问。
In C++ you have things like template metaprogramming that resolve in compile time several situations where C or any other procedural programming language would have to do in runtime.
I should say more. Template metaprogramming and some class inheritance tricks are really amazing. It can save you a lot of processing time that you'd spend otherwise by "ifing" and "switching".
This means that C++ can be actually faster than C if well conducted.
Obviously you can program "in C" using C++ and you'd have no penalty at all.
If you're not too fond of C++ I'd advise you to do a "C on C++" or "C with C++ extensions" just to take vantage of C++ improvements, but the real advantage you'll have is by programming the C++ way. There you will see that C++ is, good part of times, or faster or cleaner than C or, at least as fast as.
Have no fear. Face C++.
After the stdc++ (against libc) there will be almost no overhead in code size. If your application is from median to high in size, it will be diluted.
I use C++ from simple 8-bit ATmega to Marvell's ARM9, passing through AVR32 UC3 and Cortex-M3 and always find it profitable.
If you need specific advise in a given situation, feel free to ask.
选择 C 而不是 C++ 的主要原因是编译后的二进制文件的大小,这对于嵌入式系统来说可能是一个真正的限制。
在性能方面,如果您正确使用语言,则没有可测量的差异。您可以像编写慢速 C++ 一样轻松地编写慢速 C 代码,只要您了解所编写内容的底层机制,您就可以使用其中任何一种代码。
The main reason for choosing C over C++ is size of the compiled binary, which can be a real restriction for embedded systems.
On performance, there's no measurable difference, if you use the language right. You can write slow C code just as easily as slow C++, as long as you're aware of the under-the-hood mechanisms of what you're writing you should be fine with either.
只要限制所使用的功能,与 C 相比,C++ 的性能不会有太大影响(如果有的话)。您需要避免的功能包括:异常、RTTI 以及保持类层次结构尽可能平坦(并谨慎使用虚拟函数)。
As long as you limit the features you use, you won't have much, if any, performance hit in C++ over C. The features you'll want to avoid include: exceptions, RTTI, and keep your class hierarchy as flat as possible (and use virtual functions sparingly).
只要嵌入式系统中有足够的 RAM 和闪存,C++ 就可以。 C++ 运行时库 (libstdc++) 很大,即使您只使用 C++,它也是 C 标准库 (libc) 之外的补充。
C++ is fine as long as you have enough RAM and flash in your embedded system. The C++ runtime library (libstdc++) is big, and comes in addition to the C standard library (libc) even if you use C++ only.
您可以使用 C++,但要格外小心。
对于大小,请密切关注链接器映射文件。您可以通过看似无辜的声明找到它,其中包括大量您不需要的东西。
对于速度、配置文件或随机暂停经常。执行比实际需要更多的
new
和delete
是非常容易的,特别是对于容器类,并且要非常小心迭代器之类的东西。他们常常会不请自来地帮你。
您可以在汇编语言级别单步调试代码,以确保它只执行您实际需要的操作,这应该与 C 代码大致相同。
You can use C++ but be extra careful.
For size, keep a close eye on your linker map file. You can find it including tons of stuff you don't need, just from an innocent-looking declaration.
For speed, profile or random-pause often. It's super easy to do more
new
s anddelete
s than you really need, especially with container classes, and be really careful with things like iterators.Often they're doing you un-asked-for favors.
You can step through the code at the assembly-language level to make sure it's only doing what you actually need, which should be about the same as the C code.
无论是嵌入式还是其他方式,实现代码大小和速度高效的真正关键是程序员充分理解其决策的含义。
在某种程度上,C++ 提供了更多机会,让昂贵的东西看起来看似无辜。与 C++ 功能等效的功能通常需要在页面上花费更多的笔墨,这可能会导致对其潜在费用的更多考虑。但这绝不是绝对的——C(及其库)也有看似无辜的费用的风险。
最终,没有什么可以替代理解您在每一行代码中所要求的内容。
The real key to size and speed efficient code, embedded or otherwise, is for the programmer to fully understand the implications of his orher decisions.
To an extent, C++ provides more opportunities where something expensive can look deceptively innocent. Equivalent functionality to C++ features often requires more ink on the page, which may lead to a little more contemplation of its potential expense. But it's by no means an absolute - C (and its libraries) has the risk of deceptively innocent expense too.
Ultimately there is no substitute for understanding what you have asked for in each line of code.
我使用 ARM9 板进行硬件控制,并在 500 Mhz 板中使用 C 和 C++ 应用程序。由您决定使用该语言以及如何实现逻辑来实现功能。因为我在控制硬件的一天中运行我的应用程序时没有发现任何问题。
在编写程序时,请仔细选择变量,根据额外的指令/循环、初始化检查它。编译时也使用 Gcc 优化标志。
我在 500 Mhz ARM 9 板上运行 Qt 应用程序和 C 程序没有任何问题。
I am using ARM9 board for hardware control and I am using both C and C++ Application in 500 Mhz board. It is up to you to use the language and how you implement your logic to implement the functionality. Because I have not found any problem running my Application over the day controlling the hardware.
While writting your program, carefully select your variable, check it against extra instruction/loop, initialization. also use Gcc optimization flag while compilation.
I have not any problem running my Qt Application and C program on 500 Mhz ARM 9 board.