When to use C over C++, and C++ over C?

Question

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 one of the "ultrafast" languages out there, 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

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: 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.
@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.
@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 · Answer 1 · 2011-10-09 20:13:59Z

up vote 82 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++.

edited Oct 9 '11 at 20:13

answered Oct 9 '11 at 20:01

sbi
7,31321840

5

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

3

@Coder: I suppose that, in an OS kernel, you simply must not call any functions that might raise exceptions. Since there is very few stuff in the language/std lib that throws exceptions, and since most of it (like new) is ruled out in an OS kernel anyway, I do not see how this applies. – sbi Oct 10 '11 at 6:28

1

Note, however, that Comeau C++ produces C as output, and they provide porting to almost any C compiler, so essentially anything that supports C can also support C++, though it might require enough more resources, that on a small system it would have to be run as a cross-compiler (even though the C compiler ran natively). – Jerry Coffin Oct 10 '11 at 6:29

2

@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

2

@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

show 8 more comments

feedback

Jerry Coffin · Answer 2 · 2011-10-09 22:19:46Z

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..."

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).
+1, and for the record, I regularly write C++ code for 8-bit processors with 4KiB ROMs.
+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: 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.

Casey Patton · Answer 3 · 2011-10-11 04:10:35Z

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.)

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.
@CaseyPatton: Basically, I downvote every answer that presents this rhetoric rant uncommented as if it were a real argument.
@Coder: I agree with you. I have been coding in C++ for over 15 years now and I keep coming across features I did not know of (and the language keeps growing :-) ). This is especially annoying when working in a larger team where each programmer uses their own dialect of the language: it makes reviewing and debugging code more time-consuming and error prone. In this respect I find C code much easier to read. But, yes, I miss containers and OOP when programming in C. So I guess you have to choose according to the kind of project you are working in.

Coder · Answer 4 · 2011-10-10 01:05:46Z

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.

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.
@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.)
@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.)
@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>.
@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.)

DeadMG · Answer 5 · 2011-10-10 09:25:51Z

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.

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++.
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.
@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: 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.
@ZanLynx: So basically what you are saying is - "you can disable exceptions and still use the standard library, but only if you want to write incorrect programs".

stackoverflowuser2010 · Answer 6 · 2011-10-11 00:02:05Z

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.

Your final sentence isn't a reason to use C. You can call C libraries from C++.

anon · Answer 7 · 2011-10-11 02:31:47Z

(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.

Macke · Answer 8 · 2011-11-29 20:42:13Z

C is 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)

kylben · Answer 9 · 2011-10-09 18:36:34Z

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.

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.
@JerryCoffin: i'm intrigued; how's C more difficult to prove correct?
Javier, I'll play devils advocate: access control (private, etc), and encapsulation, plus C++'s type system is stronger.
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.
@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.

Javier · Answer 10 · 2011-10-10 03:06:05Z

up vote 0 down vote

There are times to drive a truck, there are times to ride a bike.

Personally, I think C++ is one of the most powerful languages out there; but I feel happier when writing C.

answered Oct 10 '11 at 3:06

Javier
3,334615

4

How the hell is listing personal prejudices and preferences supposed to help someone to decide based on rational arguments? (Yes, this presumes the answer seeks rational arguments. So?) – sbi Oct 10 '11 at 6:21

@sbi: see your point, but I don't think these are prejudices. Rational arguments are important, and well represented here (most tend to favor C++), but subjective observations are valuable too. We all know that in most of the arguments between 'hard' and scripting languages, the points in favor of the latter are soft ones like productivity or popularity; in my personal case, C has similar effect because of similar cause: I like it – Javier Oct 10 '11 at 16:58

feedback

Ron · Answer 11 · 2011-10-13 02:34:16Z

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.

http://www.cprogramming.com/tutorial/c-vs-c++.html

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.

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.
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.
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.
Well, isn't there some overhead, e.g. when resolving the address of virtual methods? In this respect, calling a virtual method is heavier than calling a plain C function. Do this a few million times and maybe there is a small difference.
@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.

Calmarius · Answer 12 · 2012-03-18 21:55:06Z

Several points not mentioned yet:

In C, there is no implicit behavior. What you see between the { and } will be executed, nothing more, nothing less. In C++, variable initialization and declaration may invoke constructors, destructors are called when the variable goes out of scope. Operators can be overloaded, so an innocent looking a+b may launch nukes or format your hard drive. Functions can be overloaded in C++ too, so you need to think which one will be called when reading the code, etc.
OOP is the only true way of programming, and criticizing it is like swearing in the church... But if you need something that runs very fast, you need to work with continuous arrays of data instead of encapsulating data them in objects to utilize the CPU's cache. An L2 cache miss costs hundreds of CPU cycles. (http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf)

I think C is a tool in the toolbox to write the low level magic in, export it to a dll, then use it in an OOP language like C# or Java.

'OOP The only true way' ? i beg to differ! and for the record - I love swearing in church!

A T · Answer 13 · 2011-10-10 12:02:15Z

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

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.
The C++11 preview standard references C99, which means what you've said will not be true very soon!
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.
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.

asked	7 months ago
viewed	4,077 times
active	1 month ago

When to use C over C++, and C++ over C?

13 Answers

Your Answer

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

Welcome!

Community Bulletin

Visit Chat

Linked

When to use C over C++, and C++ over C?

13 Answers

Your Answer

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

Welcome!

Community Bulletin

Visit Chat

Linked

Related