- Forum
- General C++ Programming
- C vs C++ - Request for more information
C vs C++ - Request for more information ...
Pages: 12
Hello,
I know this is a debate that has been raging and debated forever, but I am wondering if there is any definitive information on this: is C faster than C++ (assuming both the C program and the C++ program is properly written)?
I am looking for a academic paper or white paper that gives information on this.
Thank you for your time.
I know this is a debate that has been raging and debated forever, but I am wondering if there is any definitive information on this: is C faster than C++ (assuming both the C program and the C++ program is properly written)?
I am looking for a academic paper or white paper that gives information on this.
Thank you for your time.
Last edited on
Which is better for cleaning; bleach or ammonia? The answer to both of our questions will require far more data then what you've provided here. The important thing is that you avoid mixing the two together! :P
It's generally acknowledged that C is faster then C++ because there is less "overhead" included into the compiled code by default. But in reality you can't come up with a non-arbitrary answer to an arbitrary question.
It's generally acknowledged that C is faster then C++ because there is less "overhead" included into the compiled code by default. But in reality you can't come up with a non-arbitrary answer to an arbitrary question.
C++ is usually faster for sufficiently complex programs, prototypical example is std::sort vs qsort (not saying that one can't write a custom sort in C, but zero-cost abstraction in C++ is a lot more capable)
It all depends on the type of task. In general, well written C code is as fast or a little faster than the same task written in C++, but that all depends on the quality of programming. Some tasks can be written to optimize for speed at the cost of the amount of space needed, or optimize for space but make it very slow. Sorting has some famous examples. Merge sort is very fast, but requires a huge amount of memory. Selection sort is very slow but requires almost no extra memory to accomplish the task. This is true for many other programming tasks as well.
Last edited on
The real answer is neither as they are languages and the speed would depend on the compiler. You could have the worlds worst compiler In c and the worlds best in c++ and then surely c++ would be faster though if they are even grounds the difference in speed is probably trivial.
Thanks to all of the replies!
Very helpful.
I guess this is coming from hearsay but from what I can gather with the advances of modern compilers and C++11/14 any advantages that original C use to have is mute.
That is, that a modern C++11/14 compiler would create faster C++ code than "C" code.
Is that a correct understanding?
Very helpful.
I guess this is coming from hearsay but from what I can gather with the advances of modern compilers and C++11/14 any advantages that original C use to have is mute.
That is, that a modern C++11/14 compiler would create faster C++ code than "C" code.
Is that a correct understanding?
On the platform I work on, the C and C++ compilers both generate platform specific object code and use exactly the same back end optimizer. I'm hard pressed to think of any code strutures that would generate different object code, so the argument of which is faster is mute. To me, the real question is which is more productive to write in and that is C++, hands down.
You can also set your compiler (if supported; I'm sure you can do it with VS) to generate larger code, but faster or specify many other aspects of performance.
So when people code in "C" and tell people they do so because of performance reasons, do you feel that their sentiments have any merit?
The speed is identical. A C elitist (think Linus Torvalds) probably told you that nonsense.
The only reason why you generally don't see C++ used in low level applications are because a few features aren't desired or possible in embedded programming (exceptions, templates, inheritance, new/delete operators). When you remove them you essentially just have C with classes. You might as well just be using pure C at that stage.
Now that I think of it... another reason why C++ isn't used in embedded platforms is because the vast majority of them don't even have or have good C++ compilers, but have pretty good C compilers.
The only reason why you generally don't see C++ used in low level applications are because a few features aren't desired or possible in embedded programming (exceptions, templates, inheritance, new/delete operators). When you remove them you essentially just have C with classes. You might as well just be using pure C at that stage.
Now that I think of it... another reason why C++ isn't used in embedded platforms is because the vast majority of them don't even have or have good C++ compilers, but have pretty good C compilers.
Last edited on
| When you remove them you essentially just have C with classes. You might as well just be using pure C at that stage. |
Cubbi's right. It's not about who can wrjte a better "hello world" program, it's about scaling with increasingly complex systems.
Last edited on
I wrote this article ages ago, I don't know how accurate it is:
http://www.LB-Stuff.com/cc
http://www.LB-Stuff.com/cc
Last edited on
| The speed is identical. A C elitist (think Linus Torvalds) probably told you that nonsense. |
Actually, for the sake of another's reputation, Linus Torvalds was never concerned with the speed associated with C++. He was concerned about the poor code quality being churned out by C++ developers. He believes C++ encourages poor practice and isn't fit for low-level programming at all.
http://harmful.cat-v.org/software/c++/linus
C and C++ have no concept of speed. There's not really much else to say. One might realistically benchmark better than the other but that has nothing to do with the language itself. The implementation of either language can always be improved.
> a modern C++11/14 compiler would create faster C++ code than "C" code.
Only because modern C++ optimisers 'understand' the standard library and make heavy use of that knowledge.
Obviously, It is possible to implement move semantics in C, and write hand-crafted equivalents of the standard containers and algorithms. But it is far easier to optimise 10 lines of code which the optimiser understands than 50 lines of code which it has to analyse from scratch.
> Linus Torvalds was never concerned with the speed associated with C++.
He was, and probably still is.
In his rant, he makes two assertions:
one, that the standard C++ library and Boost 'don't work'
and two, that C++ 'has inefficient abstracted programming models'
The full diatribe is here: http://harmful.cat-v.org/software/c++/linus
Only because modern C++ optimisers 'understand' the standard library and make heavy use of that knowledge.
Obviously, It is possible to implement move semantics in C, and write hand-crafted equivalents of the standard containers and algorithms. But it is far easier to optimise 10 lines of code which the optimiser understands than 50 lines of code which it has to analyse from scratch.
> Linus Torvalds was never concerned with the speed associated with C++.
He was, and probably still is.
In his rant, he makes two assertions:
one, that the standard C++ library and Boost 'don't work'
and two, that C++ 'has inefficient abstracted programming models'
| C++ leads to really really bad design choices. ... blah blah ... - infinite amounts of pain when they don't work ... blah blah ... - inefficient abstracted programming models ... blah blah ... ... for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. ... |
The full diatribe is here: http://harmful.cat-v.org/software/c++/linus
Last edited on
| kbw wrote: |
|---|
| Really? So guaranteed intialisation, copy, move, cleanup methods stand for nothing? |
... where he then goes on to give an example of a project that uses C++ to explain that the projected is an unmaintainable mess rather than just being slow. There's also two posts there. In neither does he directly say that C++ is slow compared to C. One would sooner assume that he thinks C++ has bad design and creates wasted effort, which he directly states, rather than put words in his mouth to say that C++ is slow.
And the one time that he could have mentioned performance concerning vtables and exceptions, especially during the era of that post, he didn't... which seems to indicate he's explicitly avoiding the issue of performance in C++ during this post.
Even if he really does feel that C++ "is slow", he doesn't indicate as such with these posts and I can find no other source of information concerning his opinion on C++.
And the one time that he could have mentioned performance concerning vtables and exceptions, especially during the era of that post, he didn't... which seems to indicate he's explicitly avoiding the issue of performance in C++ during this post.
Even if he really does feel that C++ "is slow", he doesn't indicate as such with these posts and I can find no other source of information concerning his opinion on C++.
> rather than put words in his mouth
Quoting verbatim extracts, with a clear indication of the parts that were elided, and a link to the original text is not "putting words in(to) someone's mouth".
There are two different places in those extracts where performance ('inefficient', 'where efficiency was a primary objective') is specifically talked about; where he clearly states that C++ is slow.
Unless in his lexicon, 'inefficient' actually means 'not slow'.
Quoting verbatim extracts, with a clear indication of the parts that were elided, and a link to the original text is not "putting words in(to) someone's mouth".
There are two different places in those extracts where performance ('inefficient', 'where efficiency was a primary objective') is specifically talked about; where he clearly states that C++ is slow.
Unless in his lexicon, 'inefficient' actually means 'not slow'.
Last edited on
Because inefficient does not necessarily regard performance... come on dude... he even gave examples....
> Because inefficient does not necessarily regard performance...
> come on dude... he even gave examples....
In this case, inefficient clearly does refer to lack of performance.
Sep 2007 (the linked post):
He had already stated this a few months earlier.
May, 2007: https://www.youtube.com/watch?v=4XpnKHJAok8
Which should dispel all doubts about what he really meant by 'inefficient'. (Hopefully.)
Truly great examples that explain the flawless logic behind his train of thought. Tried it for a day, realised that "performance was so horrendously bad" that he could not use it, and arrived triumphantly at the one and only possible conclusion:
Absolutely gaga.
> come on dude... he even gave examples....
In this case, inefficient clearly does refer to lack of performance.
Sep 2007 (the linked post):
| In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. ... <rant>... So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. ...<rant>... If you want a VCS that is written in C++, go play with Monotone. ..<rant>... |
He had already stated this a few months earlier.
May, 2007: https://www.youtube.com/watch?v=4XpnKHJAok8
| one of the things I kind-of liked was a system called Monotone, which actually I think there was a talk at Google about them some time ago, I am not sure, it had a lot of interesting ideas, but the performance was so horrendously bad, that, I tried it for a day and realized that I cannot use it. |
Which should dispel all doubts about what he really meant by 'inefficient'. (Hopefully.)
Truly great examples that explain the flawless logic behind his train of thought. Tried it for a day, realised that "performance was so horrendously bad" that he could not use it, and arrived triumphantly at the one and only possible conclusion:
| They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess. |
Absolutely gaga.
Pages: 12