Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been introduced to Computer Science for a little over a year now, and from my experience it seems that C and C++ are both considered to be "ultrafast" languages, whereas others such as Python and such scripting languages are usually deemed somewhat slower.

But I've also seen many cases where a software project or even a small one would interleave files where a certain number n of those files would be written in C, and a certain number m of those files would be written in C++.

(I also noticed that C++ files almost always have corresponding headers, while C files not so much). But my main point of inquiry is to get a general sense of intuition on when it is appropriate to use C over C++, and when it is better to use C++ over C. Other than the facts that (1) C++ is object-oriented whereas C is not, and (2) the syntaxes are very similar, and C++ was intentionally created to resemble C in many ways, I am not sure what their differences are. It seems to me that they are (almost) perfectly interchangeable in many domains.

So it would be appreciated if someone could clear up the situation! Thanks

share|improve this question
Using C inline in C++ code is usually for certain modules that need to be highly optimized, do very low-level work closer to the hardware, or are critical for integrity of the data or even human safety and need to be auditable and proven correct. Rather than doing it all in C, the bulk of the project can take advantage of C++ features for flexible designs, while getting the benefits of C's tightness in those places where it is needed. –  kylben Oct 9 '11 at 18:49
@kylben: Many C++ guys will tell you: (1) Performance is not a reason to drop to C (perhaps to avoid virtual and a few other features which prevent optimizations, but e.g. non-virtual classes aren't inherently inefficient, and templates are a powerful abstraction tool that can actually lead to more efficient - e.g. qsort vs std::sort). (2) High importance of correctness is a reason to use C++ (typesafety, constness, private, RAII to make resource management manageable, etc.) over C. Or for that matter, use Ada or something in the first place. –  delnan Oct 9 '11 at 20:33
@Pubby8 I disagree with this. If I am working on a .c file and I see people do this, I tend to mentally flag them as not knowing what they're doing. For example, there's no need to cast from void* to another pointer type in C code, it's very distracting and typical of people who don't know C. –  asveikau Oct 10 '11 at 1:16
@kylben: (You might want to learn to properly address others in your comment replies, so they have a chance to actually see them.) That "a programmer very familiar with how the compiler turns C into asm" would work for C++ just as well. But that's simply irrelevant: If you want to dabble in asm, just write asm instead of having a compiler create it from some other language. The way it does this might change with every compiler update, after all. –  sbi Oct 10 '11 at 6:36
In my humble opinion... you use C when you want to, for me: C is much more simpler and easier to use than C++ ... C++ might look like a "C With classes", but it's not anymore, now it's a very complex language, with things like Virtual Constructors and Templates. –  dysoco Jun 21 '12 at 21:02
show 7 more comments

14 Answers

up vote 160 down vote accepted

You pick C when

  • you need portable assembler (which is what C is, really) for whatever reason,
  • your platform doesn't provide C++ (a C compiler is much easier to implement),
  • you need to interact with other languages that can only interact with C (usually the lowest common denominator on any platform) and your code consists of little more than the interface, not making it worth to lay a C interface over C++ code,
  • you hack in an Open Source project (many of which, for various reasons, stick to C),
  • you don't know C++.

In all other cases you should pick C++.

share|improve this answer
I would also add that C++ with exception model sometimes brings more trouble than it's worth, for say, OS kernels. At least that's the general feeling I have gotten while reading about stuff. –  Coder Oct 10 '11 at 0:26
@SF: C is the lingua franca? That's new. Or rather, very old. Maybe if you only converse with people who haven't learned new languages for the last 20 years, but I'd say that C knowledge isn't very common anymore. –  DeadMG Oct 10 '11 at 12:44
@SF.: As I have written elsewhere, I've been in projects that amounted to millions of LoC, and saw very few meta-stuff compared to C projects with their inevitable and ubiquitous macro hackery. (OTOH, the ability to create EDSLs when needed can be an incredibly powerful tool in your box.) As for C being the lingua franca: I'd rather stick to my term that it's the lowest common denominator. And I wouldn't want people with moderate programming skills hacking at an OS kernel. –  sbi Oct 10 '11 at 12:45
@Max: I completely disagree. C is a useless language, unless some insurmountable practical barrier prevents the use of C++. –  DeadMG Oct 12 '11 at 15:45
@Buttons: It was you who made a claim ("C++ needs more memory"), so it should be you who backs that up. And, no, I am not claiming that C++ needs less memory. What I'm saying is that features cost, no matter whether the compiler implements them for you (virtual functions) or you do them yourself (array of function pointers). –  sbi Sep 27 '12 at 9:41
show 14 more comments

There are a few reasons to prefer C. The main one is that it tends to be more difficult to produce truly tiny executables with C++. For really small systems, you're rarely writing a lot of code anyway, and the extra ROM space that would be needed for C++ rather than C can be significant.

I should also add, however, that for really tiny systems, C has problems for exactly the same reason, and assembly language is nearly the only reasonable choice. The range of system sizes within which C really makes sense is quite small, and shrinking constantly (though I'll admit, fairly slowly).

Another time/reason to use C is to provide a set of functions that you can bind to from essentially any other language. You can write these functions in C++ by defining them as extern "C" functions, but doing so restricts those functions to presenting an essentially C-life "face" to the world -- classes, overloaded functions, templates, and member functions, etc., need not apply. This doesn't necessarily restrict development to C though -- it's perfectly reasonable to use any and all manner of C++ features internally, as long as the external interface looks like C.

At the same time, I have to say that @Toll's answers (for one obvious example) have things just about backwards in most respects. Reasonably written C++ will generally be at least as fast as C, and often at least a little faster. Readability is generally much better, if only because you don't get buried in an avalanche of all the code for even the most trivial algorithms and data structures, all the error handling, etc.

Templates don't "fix a problem with the language's type system", they simply add a number of fundamental capabilities almost completely absent from C and/or C++ without templates. One of the original intents was to provide for type-safe containers, but in reality they go far beyond that -- essentially none of which C provides at all.

Automated tools are mostly a red herring as well -- while it's true that writing a C parser is less work than writing a C++ parser, the reality is that it makes virtually no difference in the end. Very few people are willing or able to write a usable parser for either one. As such, the reasonable starting point is Clang either way.

As it happens, C and C++ are fairly frequently used together on the same projects, maintained by the same people. This allows something that's otherwise quite rare: a study that directly, objectively compares the maintainability of code written in the two languages by people who are equally competent overall (i.e., the exact same people). At least in the linked study, one conclusion was clear and unambiguous: "We found that using C++ instead of C results in improved software quality and reduced maintenance effort..."

share|improve this answer
Tool support is not a red herring. Granted, nowadays we have clang. But tool support for C++ does lag behind oder languages considerably, even in the big-shot IDEs. Why is that? Simple, because until very recently there was no clang (and GCC was never an alternative). Until maybe half a year ago, if you needed an AST of C++ code, you were basically out of luck or out of thousands of dollars (if you bought the EDG frontend). –  Konrad Rudolph Oct 10 '11 at 7:26
+1, and for the record, I regularly write C++ code for 8-bit processors with 4KiB ROMs. –  avakar Oct 10 '11 at 12:20
+1 for an overall great answer. What I do not understand (I have no experience wrt. this) is why (I guess we're talking embedded?) a C compiler should produce smaller executable code than a C++ compiler given the same feature set used? Maybe you could provide some references? –  Martin Ba Oct 10 '11 at 13:23
@Martin: the main thing is that C++ includes exception handling, which (at least usually) adds some minimum to the executable size. Most compilers will let you disable exception handling, but when you do the result isn't quite C++ anymore. I suspect there's also a bit from the simple fact that many C++ compiler vendors just don't work quite as hard at producing the smallest possible output code. –  Jerry Coffin Oct 10 '11 at 15:04
"We found that using C++ instead of C results in improved software quality and reduced maintenance effort..." that is the conclusion to remember. –  Stephane Rolland Aug 14 '12 at 19:25
show 1 more comment

The differences between C and C++ have already been enumerated in detail here. While sometimes people may have legitimate reasons for choosing one or the other (C++ for OOP or C when they feel like C++'s extra features introduce undesirable overhead, for example), in my experience it usually just comes down to preference. What do the people working on this file know better and like better? I believe this is the reason most of the time, since it's true that these languages both tackle performance critical applications.

(Side-note: Check out Linus Torvads' rant on why he prefers C to C++. I don't necessarily agree with his points, but it gives you insight into why people might choose C over C++. Rather, people that agree with him might choose C for these reasons.)

share|improve this answer
+1 for Linus's rant :-} –  James Anderson Oct 10 '11 at 4:30
-1 for Linus's rant. :-{ –  sbi Oct 10 '11 at 6:18
Don't minus one me for that! Haha. I don't agree with Linus, but it's a pretty good example of WHY people might choose C over C++ (if they believe what Linus believes). I'm not commenting on the legitimacy of those reasons. –  Casey Patton Oct 10 '11 at 7:49
@CaseyPatton: Basically, I downvote every answer that presents this rhetoric rant uncommented as if it were a real argument. –  sbi Oct 10 '11 at 7:56
@Coder: You don't have to know the STL implementation at all. The very point of the STL is that you don't have to know the implementation, unless you're relying on behaviour not defined by the Standard- in which case, why bother using the Standard library? Moreover, it's more than a tad insane to not like a language because of how it's developers behave. C programmers behave like C is God's gift to Man and are too blind to see the obvious truth that C++ offers features which are fundamentally and intrinsically directly superior to C, like RAII. –  DeadMG Oct 12 '11 at 13:51
show 12 more comments

The main problem missing from the existing answers (as of the time of this posting) is the choice.

It's simple. If, for some utterly irrational reason, you feel that exceptions aren't worth the overhead, then you don't have to use them. You can still have templates, and RAII, and the Standard library, and never write a single "throw". The same goes for templates. If, for some reason, you feel they cause irrevocable (and actually important, which it is only on embedded) executable bloat, then surprise- you can use void* and sizeof(T) all day too. Nothing forces you to use any of the C++ features over C.

That's why C++ is an inherently superior language- you can cherry pick the features you want, and fall back to C-style programming when you dislike a given feature. Therefore, given that C++ is everything C is and more, it's an obvious fact that C++ is a superior language. Suggesting otherwise is like trying to suggest that 4 is greater than 5.

share|improve this answer
Following your reasoning there is no point at all in the original question and therefore it should be closed. I guess the question should be read something like: when should we restrict ourselves to the C subset of C++ (use plain C) and when does it make sense to use full C++. –  Giorgio Oct 10 '11 at 19:18
This is true, but only for cases of one person working on their own little project. In real life almost everyone spends maybe half their time working on other people's code. Unfortunately most other people "think wrong" regarding those utterly irrational reasons. –  DarenW Oct 10 '11 at 19:44
@DeadMG: How are allocators meant to report errors without throwing exceptions? Also, adding more features is not necessarily better when all that it does is add complexity or redundancy. –  Mankarse Dec 2 '11 at 4:30
@Mankarse: If you compile with the options to disable exceptions, allocators either abort the program or merrily proceed to use a null pointer, depending on the library implementation. –  Zan Lynx Jan 25 '12 at 20:56
@Mankarse: Since my experience in 2007 when I tried running a Linux system with 1 GB RAM and no swap, almost all desktop software fails in horrible awful ways when memory allocation fails anyway. –  Zan Lynx Jan 26 '12 at 7:06
show 2 more comments

I would say that the main reason why I would choose C over C++, is only when I would have to resort to "It this HAS TO BE 1000% stable" NASA kind of stuff.

C++ is ~99% C when we look at the performance, and it's a lot more productive. So even while in C you can write code that will be faster than C++ (you can use a subset of C++ without exceptions, virtual, streaming, abstractions, etc. as well, but that's basically C), the time to optimize every damn thing while STL is tested and does that already, would cost you more than the tiny performance gain you might achieve, or sacrifice because STL algorithms have been written by groups of experts, and you're probably not an expert in everything.

But, C++ has a ton of abstractions, and when under some circumstances they leak, and you get a trouble. And there are few people who know 100% of C++ gotchas, while, I guess, there are more that now all C gotchas, so writing a solution where every step is fully understood by all members of a team is a lot easier in C.

Example: Do you know when shared_ptr<smthn> will overflow it's reference count, will it throw an exception? Things like these are not cool when Shuttle has to reenter the atmosphere, at least I guess so.

Also, exception handling is very, very hard compared to error codes. It's hard to see if the class is 100% exception safe, and easy to get into leaks. A lot of high rep people have expressed this opinion.

share|improve this answer
And in which way exactly is manually managing memory "more stable" than C++' abstractions like std::string and the like? Have you ever tried to specify a platform where shared_ptr's counter would overflow? That would be one heck of a funny platform. And if you think exception handling is hard, you ought to have a look at a piece of C code that checks for every possible error on every function call. (Such code is hard to come by, I admit, but this is just an even more strong argument against your statement.) Sorry, but this is genuinely bovine excrements. –  sbi Oct 10 '11 at 6:24
@Lundin: '"It has to be 1000% stable" implementations don't allow dynamic memory allocation in the first place'. And what keeps you from doing exactly that in C++?? (And making blanket statements about my knowledge and experience rather than providing any arguments is a rather cheap rhetoric trick.) –  sbi Oct 10 '11 at 7:08
@Lundin: Good that you have started to provide arguments, rather than rhetorics. But they are weak. That you have "forgotten" one of the main features of C++ (templates), one that makes code safer (because it allows algorithms to be executed - and thus, fail - at compile-time, eliminating run-time errors), does not speak in favor of your knowledge of the language you are judging. Reduction of C++ to an OO language has been criticized before here, and for good reasons. (Besides, classes with deterministic destruction are a great tool and helpful for managing other resources than just memory.) –  sbi Oct 10 '11 at 10:11
@Lundin Of course you wouldn't want to use std::string if you don't want dynamic allocation. You'd use std::basic_string<char, std::char_traits<char>, some_allocator_here>. –  Luc Danton Oct 10 '11 at 12:29
@Coder: What do you think you prove with these? The first one is simply bad code (and would be just as bad reporting errors as return values), the second one makes a case for RAII over manual cleanup to which every half-decent C++ dev would cheer, and Joel, as much as I respect him, did say a few things I strongly disagree with. His plug for single-entry-single-exit reeks badly of an uninformed old fart who will never agree that what he learned 25 years ago is surpassed. (Mind you, I was programming 25 years ago, when SESE was the state of the art.) –  sbi Oct 10 '11 at 12:35
show 14 more comments

Things about C++ that make C programmers nervous

There's a lot of magic happening under the hood; constructors, destructors, virtual methods, templates, etc., can make C++ code a lot easier and faster to write than the equivalent C code, but harder to understand and reason through (depending on how well you know C++ and its associated conventions). Something as simple as Foo newFoo; may invoke a lot of code, depending on how the constructor for class Foo (and any classes it depends on) has been defined. This is also why the convention is to write ++it instead of it++ when iterating through a container, since postfix ++ often involves an expensive copy operation.

Depending on what you're doing, there can be some non-trivial overhead, especially for simple tasks. Take the following two programs, the first in C, the second in C++:

/* C version */
#include <stdio.h>
int main(void)
  char greeting[] = "Hello, world";
  printf("%s\n", greeting);
  return 0;
/* end C version */

/* C++ version */
#include <iostream>
#include <string>
int main(void)
  std::string greeting("Hello, world");
  std::cout << greeting << std::endl;
  return 0;
/* end C++ version */

Identical behavior, not a whole lot of difference in terms of source, but on the SLES 10 box I work on with gcc 4.1.2, the former generates an executable of ~9kb in size, whereas the second takes over 12.5kb (no optimization), almost 28% larger. The C++ string type is a lot easier to work with IMO than the C string library, and C++ streams are a lot more flexible and customizable than C streams, but for really brain-dead code like this, they may not be worth the overhead.

C++ is a huge language compared to C, with some extremely complex semantics. It takes a lot longer to get proficient with C++ than C, meaning a lot of people who claim to know C++ don't know it as well as they think they do.

Things about C that make C++ programmers nervous

C is not a secure programming language by any stretch of the imagination; no bounds checking on arrays leads to lots of exploitable behavior (be it through the now-dead gets function, or through scanf with the %s and %[ conversion specifiers). C++ at least gives you containers that throw exceptions if you try to access outside their currently defined range; all C gives you is (if you're lucky) a segmentation violation.

Memory management in C is very labor-intensive and error prone, compared to the tools C++ provides you. If you're building your own container, you're responsible for matching up all the malloc and free calls, making sure allocations are successful, backing out any partial allocations in the event of an error, etc. In C++, you just add items to or remove items from the container. If there's a problem, an exception will be thrown.

Similarly, error handling in C is a pain in the ass compared to the tools C++ provides (namely, exceptions). What's really fun is when you've allocated a bunch of memory and then hit a wall in your processing; as you have to back out, you have to release that memory in the right order. With C++ and RAII principles, this is (relatively) easy to do.

So when do I use one over the other?

If what you're writing is a bog simple, read it / muck with it / get rid of it application, whose behavior can be described cleanly in terms of inputs and outputs, and performance matters, then prefer C over C++. Otherwise, prefer C++

share|improve this answer
Memory management is complex and error prone in some cases, but especially in the embedded world it's often practical to write C programs using entirely static memory allocation. If the program links, it can't run out of memory at runtime. Can such guarantees be easily achieved in C++? –  supercat Feb 20 at 5:12
add comment

Bjarne Stroustrup maintains a list of applications and companies that use C++; you can argue about procedural vs OOP programming all you want, but you cannot argue with industry results over the last 20 years.

C++ is commonly used for large-scale, multi-man, complex projects where separate people need to work on modularised components. You can build and maintain modularised code in C, of course, but the inherent OOP nature of C++ leads to superior modularisation, testability, and code-reuse.

The C++ standard library (STL), in itself with just vectors and maps, is reason enough to use C++.

C is commonly used for embedded systems.

I would personally use C only if there is some library that has only a C API.

share|improve this answer
Your final sentence isn't a reason to use C. You can call C libraries from C++. –  EJP Oct 9 '11 at 22:46
I used c++ for a DSP project - not c –  BЈовић Sep 7 '13 at 22:40
add comment

C is portable assembly with better syntax, yielding the programmer full control of everything.

C++ on the other hand, does a lot of funky magic (virtual functions, overloading, automatic conversion, etc etc) which may not be desirable when you want to make sure you:

  • don't use more memory than you want to
  • don't access memory pages willy nilly (the vtable can be anywhere)
  • don't invoke to much code accidentally

And want something really simple to work with, since you're focused on performance.

It just has no surprises, and that's very valuable.

If you want to (and I recommend it), read the JSF coding guidelines on what you need to think about when writing C++ for military avionics control. It's a lot of traps in there that you need to be aware of, and it may catch you out. Bjarne was part of that document, so he knows what it's about.

Also, C compiles like a scalded troll struck by lightning. C++, OTOH, was probably sponsored by the same people who invested in SSD companies . :)

(Personally, I'd prefer C++ though, but I don't like it...... either. ;-P)

share|improve this answer
There are a lot of things C doesn't offer control over. Try writing efficient portable code to multiply a uint32_t by a uint32_t to yield a uint32_t result (bottom 32 bits of product). If an int is 64 bits, one must cast at least one operand to uint64_t to prevent Undefined Behavior, but having to cast to 64 bits for the purpose of computing a 32-bit result is--to put it mildly--"surprising". –  supercat Feb 20 at 5:18
add comment

(given you have equal familiarity with both languages)

Go with C++ unless there is no C++ compiler for your platform. You can write C++ code without whatever portion of the language you don't like (no classes, exceptions, virtual inheritance, whatever personal restrictions you wish to apply), and then at some time in the future, if you decide you want some of those features after all, then you can easily use them. Nothing in C++ prevents you from writing C-style code.

(given equivalent toolsets and developer knowledge) There is no reason to choose C over C++ provided your platform has a C++ compiler. You can simply limit yourself to the subset of the language you wish to today, while leaving the door open for extension later.

share|improve this answer
add comment

Both languages are excellent. I think a number of posters have detailed the strengths and the various uses for each. I will simply add this:

I see the C language perfect in 4 areas: 1) I think it's the best language to use when first learning any type of programming [combined with some Assembly and knowledge of machine code], 2) it's great for writing drivers, 3) embedded software, and 4) system software at the lowest level.

C++ is an object-oriented language, but it can also be procedural (very much in the way of C). If you're working on large-scale projects, GUI-based software, gaming software, and other types of graphically-intensive software, then I find C++, Java, or even Objective-C to be your best choice. However, there is plenty of command-line programs or system software where you might find C++ to be as good or better than C.

share|improve this answer
add comment

In my opinion there is one point missing in this discussion: It is simpler in C to provide a stable binary interface from a library. Both for usage with other languages as well as C++.

In C++ different compilers use different name mangling so consumers of a library compiled with a different compiler from the library might have issues using it. With C the binary interface, usually, is standardized for the platform.

I know that compilers nowadays often have switches to produce gcc-compatible things, but that doesn't always help.

I observe this on Solaris relatively often. The distribution and different software vendors typically use Sun Studio as, especially on Sparc systems, it often provides better results. Man open source projects are written with gcc-specific code though. Can be quite some pain to get those working together.

share|improve this answer
add comment

A few differences to consider, though they're probably not very significant on modern compilers and OS's, C++ produces "mangled" symbol names, which can be a problem in libraries. This can be gotten around, but a lot of libraries are written in C to avoid this. There can also be some issues with marshalling of the this pointer and complex types for things going across a process boundary or wire, but again, it's not a huge problem nowadays. C++ does add some unavoidable overhead such as v-tables (double dispatch of function calls) if you have any inheritance with virtual functions. Again, not a big problem on modern equipment, and if you need virtual functions you'll have to accept the overhead anyway (and inheritance and virtual functions can all be implemented in C, C++ just makes the syntax nicer and less verbose).

Compiled C++ is going to be a bit bloated compared to C in terms of speed, memory, and code size on disc, and while it is not enough to worry about in most cases, in highly constrained environments - such as embedded or systems work - it can be worth considering.

Toll's comments are all good, and I'd add that C is more amenable to being proven correct - more "deterministic" - for environments where that is an overriding concern.

share|improve this answer
Sorry, but I have to downvote this -- it's not only wrong, but harmfully so on a number of counts. C++ is not necessarily any slower than C at all (quite the opposite, in fact). Likewise, for anything but quite trivial problems, proving C correct is much more difficult. Basically, the only point on which I can really agree is that C++ does tend to produce larger executables (though for environments where that really matters, many (most?) compilers allow you to turn off exception handling. The result isn't exactly C++, but it's certainly not C either, and still gives small executables. –  Jerry Coffin Oct 10 '11 at 2:58
@JerryCoffin: i'm intrigued; how's C more difficult to prove correct? –  Javier Oct 10 '11 at 3:49
Javier, I'll play devils advocate: access control (private, etc), and encapsulation, plus C++'s type system is stronger. –  kylben Oct 10 '11 at 4:02
I think a lot of these benchmark-ish comparisons that say C++ is just as fast, just as (or more provable) etc., come from comparisons of the same or very comparable code. I'm thinking of a more everyday comparsion in the sense of accomplishing the same task in C doing things in the way that are a natural fit to C as compared to C++ doing things in the way that are a natural fit for C++. You can't really make meaningful quantified comparisons with that, but the question isn't about benchmarks, its about choice of language, and along with choice of language comes choice of approach and style. –  kylben Oct 10 '11 at 4:11
@Javier: One obvious point is deterministic release of memory. In C++ it's pretty easy to prove that a dtor matches the ctor, so memory deletion matches exactly with allocations. With C, that's next to impossible. –  Jerry Coffin Oct 10 '11 at 4:31
add comment

Disclaimer: While I did study both languages in university, I have not used them in my professional life, so certainly there are people who can give you a more complete answer.

Nevertheless, I, and many others, have asked that question before. So here is what I have gleaned about the subject:

First of all they are certainly not interchangeable. There are differences in syntax, that can be seen here.


As you know, C is a procedural language, and C++ is object oriented. This difference has many implications. C executes faster that C++ because it has less overhead. For this reason (and maybe others) C is often chosen over C++ for embedded software and also for system programming, such as the creation of software to run manufacturing equipment and drivers for computer hardware. Even modules for other programming languages are often written in C. C is more often used than C++ in situations where processing power is very limited.

Being object-oriented, C++ has advantages over C also. As you know, OOP is the standard for creating most software for many reasons, including ease of development and component reuse. Because of this, there are been many libraries that handle complex cases developed for C++ that are not available for C. C++ is often chosen over C for enterprise applications (those used in business), for graphics, for game development, for GUI development, and many more. While these can all be done in C (to some degree), C++ makes it much easier. With C++ you have to worry less about memory management than with C, where you have to do more manual programming to manage the memory usage of your application.

That's just off the top of my head. I'm sure others can add to this.

share|improve this answer
C++ does not add any overhead to a C program beyond linking one or two extra support libraries. Beyond that, the assembly code is identical, at least on GCC. –  Zan Lynx Oct 9 '11 at 21:24
Selling C++ as an object-oriented language is underselling it and missing the point. C++ is multiparadigm which may or may not be a good thing depending on what you need to do with it. –  Luc Danton Oct 9 '11 at 23:41
C++ code is just as fast as equivalent C code. Moreover, people choose to use the C++ features- if you don't like exception handling, you don't have to use it. –  DeadMG Oct 10 '11 at 9:21
@Giorgio - if one isn't calling virtual methods in C++, one would probably be explicitly dealing with messy "if" statements or dealing with arrays of pointers to functions taking pointers to structs, to implement something like polymorphism or otherwise accomplish tasks of a given complexity. –  DarenW Oct 10 '11 at 19:36
@Giorgio: Some C++ features do have a higher runtime cost than you might expect from the size of the code. However, to do the same thing in C would require much more code and have the same runtime cost. If a C++ programmer writes C-style code, it runs just as quickly as the C code would have. –  Zan Lynx Jan 25 '12 at 20:54
show 2 more comments

Pretty much anything written in C++ can be rewritten in C, same vice-versa.

Proof of OOP in C: [GObjects] 1

However, C is usually used for lower level things such as kernels and drivers. C++ was derived from C by Bjarne Stroustrup, who originally implemented it so it would compile down to C, for further compilation to C++.

C++ also has quite the complete Standard Template Library (STL), made more complete by the [Boost libraries] 2.

C++ has also been extended to support many more things, such as the web. (See [Wt] 3 and [CppCMS] 4)

So in summary, use C++ wherever possible, because it has a full STL. C++ is fully backwards compatible with C, meaning that you can write C code within C++ (if you #include the right libraries!).

1: http://developer.gnome.org/gobject/2.30/pr01.html 2: boost.org/ 3: webtoolkit.eu/ 4: cppcms.sourceforge.net/wikipp/en/page/main

share|improve this answer
Your first sentence is trivially true and uninteresting. All Turing complete languages are isomorphous. Your last sentence isn’t true, C99 has a few features not found in C++. They can of course be replicated, but it’s not fully backwards compatible, and it’s not enough to include a few headers. Some code has to be rewritten. –  Konrad Rudolph Oct 10 '11 at 12:17
The C++11 preview standard references C99, which means what you've said will not be true very soon! –  A T Oct 10 '11 at 12:31
It will still be true. Just because the standard references C99 doesn’t mean that it will adopt it. For an example of a C99 language construct that won’t exist in C++1, I raise you VLAs. –  Konrad Rudolph Oct 10 '11 at 13:38
C90 itself has features that work differently than in C++, such as name scope in structs inside structs. There aren't many, and they're usually minor, but a byte-fiddling sort of program might run into problems with the type of a character literal, for example. The compiler will catch most but not quite all incompatibilities. You can write in the common subset, but that's just C with slightly worse style. –  David Thornley Oct 10 '11 at 15:46
Quite annoyed that this answer has been reduced to -3… –  A T Jan 2 '13 at 16:13
show 1 more comment

protected by gnat yesterday

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.