我不确定这是一个有效的比较还是一个有效的陈述，但多年来我听到有人声称用 C++ 编写的程序通常比用 C 编写的程序需要更长的编译时间，而且用 C++ 编写的应用程序是通常在运行时比用 C 编写的要慢。
这些陈述有什么道理吗？
除了获得 C++ 提供的 OOP 灵活性的好处之外，是否应该纯粹从编译/执行时间的角度考虑上述比较？
我希望这不会因为过于笼统或模糊而被关闭，这只是试图了解多年来我从许多程序员（主要是 C 程序员）那里听到的关于陈述的实际事实。
问问题
9341 次
6 回答
11
我将回答这个问题的一个非常客观的特定部分。使用模板的 C++ 代码编译起来会比 C 代码慢。如果您不使用模板（如果您使用标准库，您可能会使用模板），它应该是非常相似的编译时间。
编辑：就运行时而言，它更加主观。尽管 C 可能是一种较低级别的语言，但 C++ 优化器变得非常好，并且 C++ 有助于更自然地表示现实世界的概念。如果用代码更容易表达您的需求（正如我在 C++ 中所争论的那样），那么编写更好（和更高性能）的代码通常比用另一种语言更容易。我认为没有任何客观数据显示 C 或 C++ 在所有可能的情况下都更快。我实际上建议根据项目需要选择您的语言，然后用该语言编写。如果事情太慢，请分析并继续使用正常的性能改进技术。
于 2011-03-24T14:30:29.327 回答
10
The relatively runtime speed is a bit hard to predict. At one time, when most people thought of C++ as being all about inheritance, and used virtual functions a lot (even when they weren't particularly appropriate), code written in C++ was typically a little bit slower than equivalent C.
With (what most of us would consider) modern C++, the reverse tends to be true: templates give enough more compile-time flexibility that you can frequently produce code that's noticeably faster than any reasonable equivalent in C. In theory you could always avoid that by writing specialized code equivalent to the result of "expanding" a template -- but in reality, doing so is exceedingly rare, and quite expensive.
There is something of a tendency for C++ to be written somewhat more generally as well -- just for example, reading data into std::string or std::vector (or std::vector<std::string>) so the user can enter an arbitrary amount of data without buffer overflow or the data simply be truncated at some point. In C it's a lot more common to see somebody just code up a fixed-size buffer, and if you enter more than that, it either overflows or truncates. Obviously enough, you pay something for that -- the C++ code typically ends up using dynamic allocation (new), which is typically slower than just defining an array. OTOH, if you write C to accomplish the same thing, you end up writing a lot of extra code, and it typically runs about the same speed as the C++ version.
In other words, it's pretty easy to write C that's noticeably faster for things like benchmarks and single-use utilities, but the speed advantage evaporates in real code that has to be robust. In the latter case, about the best you can usually hope for is that the C code is equivalent to a C++ version, and in all honesty doing even that well is fairly unusual (at least IME).
Comparing compilation speed is no easier. On one hand, it's absolutely true that templates can be slow -- at least with most compilers, instantiating templates is quite expensive. On a line-for-line basis, there's no question that C will almost always be faster than anything in C++ that uses templates much. The problem with that is that a line-for-line comparison rarely makes much sense -- 10 lines of C++ may easily be equivalent to hundreds or even thousands of lines of C. As long as you look only at compile time (not development time), the balance probably favors C anyway, but certainly not by nearly as dramatic a margin as might initially seem to be the case. This also depends heavily on the compiler: just for example, clang does a lot better than gcc in this respect (and gcc has improved a lot in the last few years too).
于 2011-03-24T15:58:17.490 回答
6
仅当您使用某些特定于 C++ 的功能时，C++ 与 C 的运行时间才会受到影响。与返回错误代码和直接调用相比，异常和虚函数调用会增加运行时间。另一方面，如果您发现自己在 C 中使用函数指针（例如 GTK 所做的），那么您至少已经为虚函数付出了一些代价。并且在每个函数返回后检查错误代码也会消耗时间——当你使用异常时你不会这样做。
另一方面，C++ 中的内联和模板可能允许您在编译时做很多工作——C 推迟到运行时的工作。在某些情况下，C++ 最终可能比 C 更快。
于 2011-03-24T14:36:07.550 回答
5
If you compile the same code as C and C++, there should be no difference.
If you let the compiler do the job for you, like expanding templates, that will take some time. If you do the same in C, with cut-and-paste or some intricate macros, it will take up your time instead.
In some cases, inline expansion of templates will actually result in code that is more specialized and runs faster than the equivalent C code. Like here:
http://www2.research.att.com/~bs/new_learning.pdf
Or this report showing that many C++ features have no runtime cost:
于 2011-03-24T14:47:33.383 回答
4
Although its an old question I'd like to add my 5cents here, as I'm probably not the only one who finds this question via a search engine.
I can't comment on compilation speed but on execution speed:
To the best of my knowledge, there is only one feature in c++ that costs performance, even if you don't use it. This feature are the c++ exceptions, because they prevent a few compiler optimizations (that is the reason, why noexcept was introduced in c++11). However, if you use some kind of error checking mechanism, then exceptions are probably more efficient than the combination of return value checking and a lot if else statements. This is especially true, if you have to escalate an error up the stack.
Anyway, if you turn off exceptions during compilation, c++ introduces no overhead, except in places where you deliberately use the associated features (e.g. you dont't have to pay for polymorphism if you don't use virtual functions), whereas most features introduce no runtime overhead at all (overloading, templates, namespaces a.s.o.). On the other hand, most forms of generic code will be much faster in c++ than the equivalent in c, because c++ provides the built-in mechanisms (templates and classes) to do this. A typical example is c's qsort vs c++'s std::sort. The c++ version is usually much faster, because inside sort, the used comparator function is known at compile time, which at least saves a call through a function lookup and in the best case allows a lot of additional compiler optimizations.
That being said, the "problem" with c++ is that it's easy to hide complexity from the user such that seemingly innocent code might be much slower than expected. This is mainly due to operator overloading, polymorphism and constructors/destructors, but even a simple call to a member function hides the passed this-pointer which also isn't a NOP.
Considering operator overloading: When you see a * in c, you know this is (on most architectures) a single, cheap assembler instruction, in c++ on the other hand it can be a complex function call (think about matrix multiplication). That doesn't mean, you could implement the same functionality in c any faster but in c++ you don't directly see that this might be an expensive operation.
Destructors are a similar case: In "modern" c++, you will hardly see any explicit destructions via delete but any local variable that goes out of scope might potentially trigger an expensive call to a (virtual) destructor without a single line of code indicating this (ignoring } of course).
And finally, some people (especially coming from Java) tend to write complex class hierarchies with lots of virtual functions, where each call to such a function is a hidden indirect function call which is difficult or impossible to optimize.
So while hiding complexity from the programmer is in general a good thing it sometimes has an adverse effect on runtime, if the programmer is not aware of the costs of these "easy to use" constructs.
As a summary I would say, that c++ makes it easier for inexperienced programmers to write slow code (because they don't directly see inefficiencies in a program). But c++ also allows good programmers to write "good", correct and fast code faster than with c - which gives them more time to think about optimizations when they really are necessary.
P.S.:
Two things I haven't mentioned (probably among others that I simply forgot) are c++'s ability for complex compile time computations (thanks to templates and constexpr) and c's restrict keyword. This is because didn't use either of them in time critical programs yet and so I can't comment on their general usefulness and the real world performance benefit.
于 2014-05-16T14:50:22.433 回答
-1
C 应用程序的编译和执行速度比 C++ 应用程序快。
C++ 应用程序在运行时通常较慢，并且编译速度比 C 程序慢得多。
看看这些链接：
于 2011-03-24T14:30:53.740 回答