Is C really faster than C++?

views:

383

answers:

+2 Q:

Is C really faster than C++?

At begning I used to believe, since C++ is superset of C, there should'nt be a reason for C++ being slower than C but many people on SO dont think so http://stackoverflow.com/questions/2245196/c-urban-myths/2245221#2245221.

Is it true that C++ is slower than C? If not, why to use C anyway?

+11 A:

C++ is not a superset of C.

Programs can be made in both languages which are equally as efficient, or equally as bad.

The argument probably comes from that in any higher language level language, you will have more higher level features available to you and you will likely use them. If you re-implemented these features in the lower level language then you'd probably be worse off. But not having them in the lower level language probably means you are less likely to use them.

Likely any program you make in either language, you will not notice a difference.

Brian R. Bondy 2010-09-13 17:17:28

On the other hand, if you end up replicating C++ v-tables with arrays of function pointers in C, you've gained nothing in performance, and lost in simplicity.

Eclipse 2010-09-13 17:23:42

“this is slightly slower than not doing so” is again misleading: because using features such as virtual functions where needed will most probably be *faster* than other equivalent code that’s hand-written instead of compiler-generated.

Konrad Rudolph 2010-09-13 17:23:47

Are you sick of saying "C++ is not a superset of C" yet? Have you got a macro setup? :)

torak 2010-09-13 17:24:59

@torak: Yes it's F7 lol

Brian R. Bondy 2010-09-13 17:26:19

This is totally misleading. Using features of C++ and saying they are slower is only half the answer. You can not look at the feature in isolation you must also look at the cost of implementing the same functionality in C. So an equivalent program in C/C++ will be the same. Unfortunately implementing all the extra functionality that is already done automatically in C++ you are unlikely to implement the feature as effeciently in C (because the compiler team has has 10 years to optimize it).

Martin York 2010-09-13 17:37:49

@Martin York: I just mean that having more functionality available for you, you are more likely to use it. I do not think that re-implementing that exact functionality in C would be faster. I agree with your point.

Brian R. Bondy 2010-09-13 17:48:08

@Martin York: I reworded better now what my intent was.

Brian R. Bondy 2010-09-13 17:51:02

+7 A:

Are you realizing that "C++ is slower than C." is meant to be a myth, so it actually says "C++ is not slower than C."? That one comment to that answer isn't really serious.

Is it true that C++ is slower than C? If not, why to use C anyway?

"Is it true that a Ferrari is slower than a Ford? If not, why to use a Ford anyway?".

Johannes Schaub - litb 2010-09-13 17:20:09

The speed of the program depends way more on the programmer than on the language. C++ is the standard language in financial services (not a sector that's tolerant of slow code) for high-performance applications. If C was that much faster, it would be used instead.

There is a trade-off between development speed and execution speed too of course. If perf was all that mattered we would all be writing assembler code 100% of the time.

Steve Townsend 2010-09-13 17:20:10

+2 A:

Languages dont have a speed that can be compared. I think what you wanted to ask is if code compiled with a C compiler is faster than that compiled with a C++ compiler. And the answer is... depends on which compilers you compare and the nature of the code that gets compiled.

GrandmasterB 2010-09-13 17:21:56

C++ can be coded as C and therefore should not be any slower (assuming the same level of optimization in the compiler and libraries).

If coded OO, however, it should be significantly slower. Good OO code is going to require lots of heap allocation (whereas otherwise you could keep most stuff on the stack) and small space allocations--pure c can get away with very little outside of stack allocations. Also OO tends to need an extra level or two of indirection on every single method call.

Bill K 2010-09-13 17:23:00

-1: you should practise OO programming more, yes poorly coded C++ can be like what you describe, but no poor coding is not an OO requirement. Code what should be in an object in a method of that object and extra levels of indirection disappear (and, yes, STL interface is quite often a bait to poor coding).

kriss 2010-09-14 06:44:17

@kriss Actually you're quite wrong. Poorly coded OO can be performant, well coded OO is generally not. The thing is, the code is best written to be most easily parsed by humans, not machines. I happen to love OO, but unless you are constantly thinking in terms of performance and not good design, it will not perform as well. If you are ever thinking of performance when coding, you are not doing it right--performance should be your very last concern. C++ makes this tough which is one of the reasons C++ is such a poor OO language.

Bill K 2010-09-14 17:16:48

@Bill K: This is quite a surprising statement. My experience of heavily using TDD and refactoring rules (rules written to make code simpler, easy to read and to maintain, not to make it fast), also makes it faster. Rules like passing reference to complex objects make to reduce number of parameters, rules like using local methods makes code faster, etc. Really I can't see any refactoring rule that would make code slower. On the other hand I have seen blind use of design patterns and over-engeenering making code much slower. But there is probably ground to open a question on the subject.

kriss 2010-09-14 20:59:32

@kriss yes, but Good OO has things like hundreds of tiny short-lived objects as opposed to a few big ones and no ownership (as opposed to objects allocated on the stack). If you create objects and pass them off, anyone may or may not keep a reference to it--it shouldn't matter. Outside of OO code I generally agree with your previous statement. I think that C++ programmers have a lot of trouble with OO because to do good OO is contrary to most C++ practices. Most objects should only have a couple complex method, each fitting on a page (very approximately). I rarely see this in C++.

Bill K 2010-09-14 21:53:26

@kriss Oh, also the very nice practice of making classes immutable wherever possible--a lot more throwing away and regenerating rather than reusing (often) heap-allocated memory. Java may generate, modify, tear apart and release dozens strings in just a few lines of code--but generally has optimized them so that this really doesn't affect performance much any more--the design can be human readable, reliable, and you don't have to worry about which ones you can return (because none are stack-allocated, all heap)

Bill K 2010-09-14 22:17:39

I don't think the "slower/faster" you are referring to really exists here.

C/C++ are both programming languages with their own compilers. Each will convert your program into a lower level language one way or the other. You might end up finding tons of differences among both, but they really all end up to the ease of use of a programmer. Yu cannot say one is faster just because it came later. These are not fixes that are released. these are new programming languages, created by new people in a new style.

If your theory goes on....then java should remove c++ from the world & c# should remove java from the world.... hold on, nooooo vb should remove everything else??? :p Just to let you know of the consequences of your query.

loxxy 2010-09-13 17:24:18

ansaurus

tags:

views:

answers:

Is C really faster than C++?

related questions