Although people seem to like to complain about C++, I haven't been able to find much evidence as to why you would want to choose C over C++. C doesn't seem to get nearly as much flak and if C++ has all these problems why can't you just restrict yourself to the C subset? What are your thoughts/experience?
-
exact duplicate link no longer works.....says the guy who is late to the c party :) – kyle Sep 04 '14 at 14:56
-
5C is really better and simpler to C++ but any C programmer can convert C++ to C and laugh. – BobRun Oct 16 '15 at 18:18
-
14The frightning thing is people in general think "++ " means this is really gooooood , well sorry it is not. – BobRun Oct 16 '15 at 18:29
-
Apart from the obvious - small / embedded devices - generally C is better for pure number crunching problems (e.g. GPU graphics processing, massively parallel physics calculations, pattern mining etc) where OOP features are a bloat. C++ is better for modelling systems where 'things' interact, much easier with OOP capabilities. – Paceman Oct 25 '16 at 11:29
-
3Because JavaScript, best practices, c++, and OOP are stupid/too busy trying to solve these abstract problems which probably don't really exist or need to be solved ever. – marshal craft Jan 26 '17 at 11:48
-
Like for example new operator. – marshal craft Jan 26 '17 at 11:55
-
For me it's the simpler type system. It means I can implement a generic data structure which just copies and moves bits and bytes around without having to worry about copy constructors and destructors and all that stuff. That lets me focus more on things like memory access patterns and layouts than spending all day having to respect a rich type system. With C I can kind of blur the boundaries between memory allocator and data structure more easily. If I want type safety, I use C++. When I want to work with memory in a homogeneous way, I use C. In C++, `memcpy` is a no-no since it bulldozes... – Dec 10 '17 at 04:15
-
... over the features of the type system. In C, it's a daily function to use since the type system is so simple and basic in C. Also exception-safety is really hard to achieve in low-level code like core data structures when any function called on `T` (except dtors) can possibly throw. It's so much easier if you don't have to worry about anything throwing in those areas and focus the exception-handling in high-level areas where everything is already behind the safe confines of a RAII-conforming resource. When you need low-level code, C is actually easier because it has less features. – Dec 10 '17 at 04:16
-
Because Linus Torvalds says so? – Gayan Weerakutti Apr 08 '18 at 04:21
-
Why would anyone use c++ over c... seriously? C++ is just a bloated mess. – Fredrik Nov 29 '18 at 23:13
25 Answers
Joel's answer is good for reasons you might have to use C, though there are a few others:
- You must meet industry guidelines, which are easier to prove and test for in C
- You have tools to work with C, but not C++ (think not just about the compiler, but all the support tools, coverage, analysis, etc)
- Your target developers are C gurus
- You're writing drivers, kernels, or other low-level code
- You know the C++ compiler isn't good at optimizing the kind of code you need to write
- Your app not only doesn't lend itself to be object-oriented but would be harder to write in that form
In some cases, though, you might want to use C rather than C++:
You want the performance of assembler without the trouble of coding in assembler (C++ is, in theory, capable of 'perfect' performance, but the compilers aren't as good at seeing optimizations a good C programmer will see)
The software you're writing is trivial, or nearly so - whip out the tiny C compiler, write a few lines of code, compile and you're all set - no need to open a huge editor with helpers, no need to write practically empty and useless classes, deal with namespaces, etc. You can do nearly the same thing with a C++ compiler and simply use the C subset, but the C++ compiler is slower, even for tiny programs.
You need extreme performance or small code size and know the C++ compiler will actually make it harder to accomplish due to the size and performance of the libraries.
You contend that you could just use the C subset and compile with a C++ compiler, but you'll find that if you do that you'll get slightly different results depending on the compiler.
Regardless, if you're doing that, you're using C. Is your question really "Why don't C programmers use C++ compilers?" If it is, then you either don't understand the language differences, or you don't understand the compiler theory.

- 7,482
- 3
- 14
- 34

- 91,931
- 60
- 264
- 330
-
2There's also the MISRA C standard, which AFAIK isn't yet really stable for C++. – Paul Nathan Jan 31 '09 at 01:25
-
71The performance part isn't necessarily true. There are plenty of areas where C++ can optimize far better than C. (Of course the reverse is also occasionally true, but generally, choosing C over C++ for performance reasons is a bad idea). – jalf Jan 31 '09 at 17:25
-
12I'd be interested in more performance information. I don't understand why C would only perform better "occasionally." Given an average programmer, it may be that C++ makes performance easier to attain (good use of patterns) but a C program written by an expert should be faster - lower overhead. – Adam Davis Jan 31 '09 at 19:58
-
3Of course, the faster C program would take longer to write and debug, so there's a tradeoff, and given the speed of machines the tradeoff is rarely worth it except for specialized applications, which is why C++ is generally better. (by the time the code is done, computers are faster and eat the dif) – Adam Davis Jan 31 '09 at 19:59
-
2But most code written in the world goes into embedded processors, and often there are code size/performance contraints where C shines. Lower power, direct control over the processor and peripherals, etc - sometimes beats out the advantages of C++. – Adam Davis Jan 31 '09 at 20:01
-
1But I'm not trying to say one is better than the other - in fact, I admit that only under certain circumstances should C be considered as an option. The right tool for the right job... – Adam Davis Jan 31 '09 at 20:02
-
23@Adam: C++ performs better than C with "pretty" code. C++ can use templates and inline functions where C needs a macro. C++ overhead only appears when asked for, it is otherwise the same as C. (virtual, try/throw, dynamic_cast). Much of the overhead only shows in program image size. – Zan Lynx Feb 03 '09 at 01:41
-
6@Zan "C++ overhead only appears when asked for, it is otherwise the same as C" Great, I'd really like to see some references. – Adam Davis Feb 03 '09 at 14:13
-
2@Adam: Personal experience, and to make sure I just compiled an identical hello world C program with gcc and g++ and the object code for main was identical, only a bit of library loading was different. Provide your overhead references. – Zan Lynx Feb 03 '09 at 20:54
-
1Ah. I'm not trying to start a c vs c++ war here. As I've said earlier, only under certain circumstances would I recommend anyone use C. In general they are on par with each other. But for certain problems C is _sometimes_ a better choice. It's an old tool well past its prime - but still useful. – Adam Davis Feb 04 '09 at 01:59
-
1I would add that writing nice understandable and clean code in c++ is very dificult. – Iharob Al Asimi Jan 13 '15 at 20:16
-
1I came looking for answer to different question, why teach people in C and java, instead of using C++ for both, but found this answer to be very informative. +1 – Tom Jun 19 '15 at 21:02
-
2
-
1My two cents: I partially agree with Adam, and partially with the others, especially jalf and Zan Lynx. Coming from a science background where most programs are simulation software or long computations, often procedural approach makes much more sense. Sure, one can write procedural code in C++, but C makes sense for reasons mentioned in the answer: essentially easier to read/maintain, other developers are more experienced in C, code looks cleaner (believe it or not). I've worked on projects where a few milliseconds made a difference. After some benchmarks, C won. – Apr 17 '16 at 17:04
-
4For numerical computations, you can actually have more efficient C++ code than C code, by using lazy evaluation via templates. See [Eigen](http://eigen.tuxfamily.org/index.php?title=Main_Page). In fact, functionality like sort can be [faster in the C++ STL](https://isocpp.org/wiki/faq/c#sort-qsort) rather than the C standard library. AFAIK, the only situation where C++ binaries perform worse than C binaries is when the C++ makes heavy use of virtual functions, but once you consider C function pointers, that difference goes away. Totally agree with @jalf. – Aditya Kashi Oct 21 '17 at 20:19
-
2Like this answer generally, but -1 for claiming C is a better idea simply because you're writing drivers, kernels or low-level code. On the contrary, rich abstraction and a focus on compile-time execution and optimization are even more important in lower-level code. Of course you wouldn't write just any sort of C++ willy-nilly, but you would definitely use it. Think of CUDA for GPU kernels, for example. – einpoklum Jan 08 '18 at 22:09
-
You may even write large enterprise applications by using some middleware, like [Enduro/X](http://www.endurox.org). Thus make a big application out of the small binaries which communicate via middleware in micro-services oriented fashion. This resembles unix philosophy, make "small, sharp tools" which are easy to maintain even for new developers. – Madars Vi Feb 17 '18 at 17:57
-
Performance wise, C++ has stronger compile-time capabilities, but in the C world, you can always fully replace that code/data generation executed as part of your build. C on the other hand has `restrict` which in the C++ world has no standardized replacement (although practically you have it as an extension), so I think if you have just pure C and pure C++ and you allow for build-time code generation, C, not C++, has one huge advantage when it comes to generating high-performance code. – Petr Skocik Apr 19 '19 at 17:19
-
1A C compiler faster than a C++ compiler for tiny programs? Like *noticeably*? Man, if it is, it's a question of milliseconds. If you "whip out your compiler" for a tiny program, you won't notice any difference. It's not even faster to type gcc than g++... – Gabriel May 22 '19 at 01:39
-
1"Your app not only doesn't lend itself to be object oriented, but would be harder to write in that form" What?!? OOP is a programming paradigm, your code doesn't become OO by going through the C++ compiler. You get access to strings and containers and using those also doesn't make your code OO. Just like using an RDBMS doesn't make the DB you create in it relational. – yeoman Oct 16 '19 at 09:58
I like minimalism & simplicity.

- 8,409
- 22
- 75
- 99

- 2,862
- 1
- 24
- 13
-
9
-
20
-
53
-
13Agree. C is very simple and "small". C always look the same and if you are a new contributor on a project, it's easy to understand how it works. c++ has some many useless things and when looking at a c++ project i just get confused instantly. I can understand the c++ people (a C language with OO capabilities) but C is just more simple and easy. – user69969 Mar 24 '14 at 18:10
-
1Also I think C is a much better suited language for writing some kind of libraries, like small universal libraries, scripting languages and, yes, rendering engines. – keebus Mar 04 '16 at 20:42
-
4I agree 100000000000000000%. A good C programmer can maintain even a large C application without getting lost in all the bullshit classes and Boost! – Vahid Amiri Sep 12 '16 at 15:14
-
1The simplicity goes away when you have to manage every single aspect of simple structures...give me automatic memory management for my 10000 pointers, or the size of my array, or a simple hash...nah...link 1000 libraries to get the job done in C emulating a C++ compiler. – wgodoy Oct 09 '18 at 17:00
-
I like how the answer follows what it states. Practice what you preach. – Jardel Lucca Feb 27 '23 at 13:18
- Because they already know C
- Because they're building an embedded app for a platform that only has a C compiler
- Because they're maintaining legacy software written in C
- You're writing something on the level of an operating system, a relational database engine, or a retail 3D video game engine.

- 399,467
- 113
- 570
- 794
-
5Some microcontrollers only have C compilers which really sucks. The basic C++ features (namespaces, classes besides virtual functions, enums, declaring variables elsewhere besides top-of-block) are the most valuable, IMHO. – Jason S Jan 31 '09 at 00:29
-
2From this it sounds like you would choose C only if there are no reasonable alternatives. – Jan 31 '09 at 00:30
-
2@Joe: aside from the first point, that about sums it up. A lot of the later languages took C and said, 'hey, we can do _better_.' – Joel Coehoorn Jan 31 '09 at 00:47
-
1Agreed. If you aren't using the sophisticated C++ features, I believe that C++ is monotonically a better C. With the more sophisticated C++ features, things get more debatable, but then the debate is usually versus a higher level of abstraction- e.g., Java. – Paul Nathan Jan 31 '09 at 01:28
-
1
-
-
5
-
Game engines aren't the only thing out there. Many microcontrollers still only support vanilla C, or you might have a legacy C code base. It's still very relevant. – Joel Coehoorn Oct 21 '17 at 20:57
Fears of performance or bloat are not good reason to forgo C++. Every language has its potential pitfalls and trade offs - good programmers learn about these and where necessary develop coping strategies, poor programmers will fall foul and blame the language.
Interpreted Python is in many ways considered to be a "slow" language, but for non-trivial tasks a skilled Python programmer can easily produce code that executes faster than that of an inexperienced C developer.
In my industry, video games, we write high performance code in C++ by avoiding things such as RTTI, exceptions, or virtual-functions in inner loops. These can be extremely useful but have performance or bloat problems that it's desirable to avoid. If we were to go a step further and switch entirely to C we would gain little and lose the most useful constructs of C++.
The biggest practical reason for preferring C is that support is more widespread than C++. There are many platforms, particularly embedded ones, that do not even have C++ compilers.
There is also the matter of compatibility for vendors. While C has a stable and well-defined ABI (Application Binary Interface) C++ does not. The ABI in C++ is more complicated due to such things as vtables and constructurs/destructors so is implemented differently with every vendor, and even versions of a vendors toolchain.
In real-terms this means you cannot take a library generated by one compiler and link it with code or a library from another which creates a nightmare for distributed projects or middleware providers of binary libraries.

- 10,351
- 4
- 44
- 67

- 58,260
- 22
- 130
- 143
-
8"Interpreted Python is in many ways considered to be a "slow" language, but for non-trivial tasks a skilled Python programmer can easily produce code that executes faster than that of an inexperienced C developer." I guess a programmer (not necessarily a Python Progammer) that took algorithms lessons can produce code that executes faster than that of an inexperienced developer (in general). – Andrei Ciobanu Mar 29 '10 at 13:01
-
25And that same inexperienced c dev will produce python code that is slower than his c code. Python is way slower than c. – Millie Smith Sep 08 '15 at 17:53
I take the other view: why use C++ instead of C?
The book The C Programming Language (aka: K&R) tells you clearly how to do everything the language can do in under 300 pages. It's a masterpiece of minimalism. No C++ book even comes close.
The obvious counterargument is that the same could be said of most, if not all, modern languages -- they also can't tell you how to do everything in only a few hundred pages. True. So why use C++ instead? Feature richness? Power? If you need something more feature rich or powerful then go with C#, Objective C, Java, or something else like that. Why burden yourself with the complexities of C++? If you need the degree of control C++ grants then I argue to use C. C can do anything and can do it well.

- 52,922
- 30
- 133
- 149
-
1I agree. I want power so I use something truly powerful, not the 1/2 way point. – Dinah Feb 02 '09 at 19:26
-
10@Dinah: The 1/2 way point gives you higher level expression power without the performance and memory cost of C# or Java. – Zan Lynx Feb 03 '09 at 01:50
-
6@Zan Lynx: you're right. But I hope by taking the opposing stance that I did in my original post that I made a point about the viability of C over C++ ... even if it is, as you point out, not an open and shut case. – Dinah Feb 03 '09 at 04:13
I choose to write in C because I enjoy working with a small, tight language. I like having access to a standard which can be read in a reasonable amount of time (for me -- I'm a very slow reader). Moreover, I use it to write software for embedded systems for which few desirable C++ compilers exist (like some PIC micro-controllers).
-
re: PICs -- I feel your pain. If I ever have to do a lot of PIC code I will probably use the IAR compiler which supports C++. I've used it on the MSP430 and it's pretty nice. – Jason S Jan 31 '09 at 00:30
-
1And don't forget the vastly improved compile times for C. No template system. – Engineer May 04 '17 at 08:16
In addition to several other points mentioned already:
Less surprise
that is, it is much easier to see what a piece of code will do do exactly . In C++ you need to approach guru level to be able to know exactly what code the compiler generates (try a combination of templates, multiple inheritance, auto generated constructors, virtual functions and mix in a bit of namespace magic and argument dependent lookup).
In many cases this magic is nice, but for example in real-time systems it can really screw up your day.

- 484
- 3
- 10
I'm used to use C++ for my projects. Then I got a job where plain C is used (a 20 year old evolving codebase of an AV software with poor documentation...).
The 3 things I like in C are:
Nothing is implicit: you see what your program exactly does or not does. This makes debugging easier.
The lack of namespaces and overloads can be an advantage: if you want to know where a certain function is called, just grep through the source code directory and it will tell you. No other special tools needed.
I rediscovered the power of the function pointers. Basically they allow you to do all polymorphic stuff you do in C++, but they are even more flexible.
-
9+1 However such polymorphism in C is usually obtained via void*, which is dangerous as it disables any ability of the compiler to check if you are doing something nasty. – gd1 Dec 20 '13 at 14:35
-
7@gd1 In practice I can't remember a single case when this `void*` caused trouble. There are many defensive programming techniques to protect against mistakes: putting asserts everywhere, adding magic numbers into your structs (in debug builds), etc. But nowadays we have valgrind, dr. memory, and even MSVC instruments the code to detect problems, so memory corruption problems are pretty easy to sort out. – Calmarius Dec 22 '13 at 17:48
-
5I almost never experience memory corruption in my programs, but if possible I would prefer mistakes to be detected before running the program. Casting `void*` to `whatever*` is something the compiler accepts in good faith. I prefer my compiler not to trust me and have the possibility to enforce robust type checks. Template substitution errors issued by C++ compilers are painful to read but at least garbage doesn't compile. – gd1 Dec 22 '13 at 19:31
-
1@gd1 Back to your first comment, I don't know how much experience do you have with procedural techniques (I see you are active in mostly OO tags). The `void*` usually can be avoided. The typical pattern when adding custom behavior is passing a function pointer and a `void*` for user data. A generic interface usually looks like this. Then the library when passes this `void*` back to your callback without doing anything else with it. Most often you don't have any extra data, so you pass NULL, and ignore the user parameter in your callback. I presumed that you knew this. – Calmarius Dec 29 '13 at 12:44
-
1@Calmarius "Most often you don't have any extra data" -> This is actually the advantage to polymorphism. It is easy to bind extra data, without using void pointers. So, your excuse is basically "I don't really use that feature anyways." – user2445507 Jul 15 '18 at 20:22
-
Linus' answer to your question is "Because C++ is a horrible language"
His evidence is anecdotal at best, but he has a point..
Being more of a low level language, you would prefer it to C++..C++ is C with added libraries and compiler support for extra features (both languages have features the other language doesn't, and implement things differently), but if you have the time and experience with C, you can benefit from extra added low level related powers...[Edited](because you get used to doing more work manually rather than benefit from some powers coming from the language/compiler itself)
Adding links:
Why are you still using C? PDF
I would google for this.. because there are plenty of commentaries on the web already

- 6,577
- 3
- 30
- 48
-
1What exactly are these "extra added low level related powers" that C has? The examples you pointed to only talk about differences in how they are commonly used. – Eclipse Jan 31 '09 at 00:42
-
23I did a lot of coding in C, then a brief period of time in C++, then an embarassingly long time with VB, and now I've been using C# for the last few years. I've written a bit of C and C++ code since then and I've realized that C is well-defined and tight, C# is cool and powerful, and C++ just sucks. – CMPalmer Jan 31 '09 at 00:48
-
@Josh, I edited the answer to be more clear..the powers come not from the language C or the compiler, but from the experience you might benefit from by doing things *the hard way* (not using extra features from C++) – Ric Tokyo Jan 31 '09 at 01:13
-
1I've said for years now I'd use C for a small module/driver/plugin and a higher-level language for a real program. I don't see any reason to use C++. Syntax and readability are just horrific. (Actually, I like to use some C++ features in my C progs, just not classes) – Bill K Jan 31 '09 at 04:44
-
27Linus is not really qualified to speak about the merits of C++. Quoting him as if he was some kind of oracle is just stupid. And the bit about "doing things the hard way" doesn't make sense. There are good reasons to use C, but "it's more work", or "Linus said so" are not among them. – jalf Jan 31 '09 at 17:31
-
11@jalf, not quoting Linus as if he is some sort of oracle, its good to mention the opinion of a know programmer for his choices in one of the most used programs in the world: the linux kernel. The question asks for opinions (why someone would choose C) its what I aimed to answer. – Ric Tokyo Feb 01 '09 at 02:45
-
7Linus is a bad source for opinions on C++ because he does not use it and as far as I know, only tried it once in 1990-something. – Zan Lynx Feb 03 '09 at 01:45
-
5@Zan Linus displayed more self control elsewhere: "We would have liked to use C++ and the extra features it brings, but its harder to see where bad code in C++ than in C". The quote on my answer is a record of an opinion rather than a "follow the leader". – Ric Tokyo Feb 03 '09 at 02:25
-
2badly worded as it may seem, this is an interesting view from an interesting guy. – Ric Tokyo Feb 03 '09 at 02:25
-
I m sure I will never write an OS or something near that, and if linux was made with C then it is a robust language, I go with C for now...end of my travel – Badr Elmers Feb 06 '22 at 14:01
Long compile times can be annoying. With C++ you can have very long compile times (which means, of course, more time for Stack Overflow!).

- 64,140
- 93
- 237
- 324
-
Why was this voted down? I do a lot of work in C++ myself and I wouldn't go back to C, but it can indeed have painfully long compilation times (think of templates, for example). – Frank Jan 31 '09 at 01:18
-
6I use C++ for real work, but I always prototype in C because of the near-instantaneous compile times. – Tom Jan 31 '09 at 02:41
-
Hmm, when done the right way, i.e. not having bloated we-may-need-these-#includes and not-sure-which-is-the-right-include-so-i-will-include-them-all-#includes the compile times are neat. When I hack on one or three files, it takes me just 1-2 seconds to compile my 100 KLOC projects. – Sebastian Mach Nov 24 '14 at 10:35
-
5@Tom: I wonder what your real work C++ looks like, if you can prototype in C. Are you not using C++' capabilities? Can you elaborate? – Sebastian Mach Nov 24 '14 at 10:36
Because they're writing a plugin and C++ has no standard ABI.

- 1,456
- 11
- 16
-
10Although true, it's not a convincing reason to stick to C because you can export the necessary functions using C linkage and still keep your implementation in C++. – codelogic Jan 31 '09 at 01:49
-
2@codelogic - C++ projects tend to export many more types and functions than the equivalent C projects. It's possible to hide this in a final shared library, but it's quite possibly more effort than it's worth. – Tom Jan 31 '09 at 02:38
-
tbh not a really good answer but +1 because C++ has no standard ABI (yes .. C++ sucks) – hasen Apr 05 '09 at 04:38
-
8
If you want your code to be understood by virtually any programmer write in C.

- 4,755
- 7
- 47
- 64
I'm surprised no one's mentioned libraries. Lots of languages can link against C libs and call C functions (including C++ with extern "C"). C++ is pretty much the only thing that can use a C++ lib (defined as 'a lib that uses features in C++ that are not in C [such as overloaded functions, virtual methods, overloaded operators, ...], and does not export everything through C compatible interfaces via extern "C"').

- 19,717
- 4
- 46
- 69

- 2,768
- 2
- 22
- 26
-
1Not so; you can extern "C" or __cdecl your functions to expose them to C. – Crashworks Jan 31 '09 at 02:01
-
-
2
-
1
-
3The most obvious reason for interoperability problems is name-mangling, and I think that's worth bringing up. – Tom Jan 31 '09 at 02:45
Because they want to use features in C99 that don't have equivalents in C++.
However, there aren't as many C99 features that are useful to C++ as people think at first glance. Variable-length arrays? C++ has std::vectors. Support for complex/imaginary numbers? C++ has a templated complex type. Type-generic math functions? C++ overloaded the standard math functions, causing the same result.
Named initializers? Not in C++, but there's a workaround:
struct My_class_params {
int i;
long j;
std::string name;
My_class_params& set_i(int ii)
{
i = ii;
return *this;
}
My_class_params& set_j(long jj)
{
j = jj;
return *this;
}
template <typename STRING>
My_class_params& set_name(STRING&& n)
{
name = std::forward<STRING>(n);
return *this;
}
My_class_params()
{
// set defaults
}
};
class My_class {
My_class_params params;
public:
My_class(const My_class_params& p) : params(p) { }
...
};
This allows you to write things like:
My_class mc(My_class_params().set_i(5).set_name("Me"));
-
1Hear, hear! The lack of named designated initializers in C++ drives me up the wall every time I have to use it. – ephemient Jan 31 '09 at 02:54
-
3
-
If you want to initialize a global structure outside of a function (so you can't .set_*()), C++ forces you to use unnamed initilizer syntax, or to write a constructor for your struct. I don't like either of those options. – ephemient Feb 01 '09 at 16:42
-
1There are also VLAs in C99 (GCC) that are much easier to work with than `std:vector`. – Vahid Amiri Sep 12 '16 at 15:19
This is pretty shallow but as a busy student I chose C because I thought C++ would take too long to learn. Many professors at my university won't accept assignments in Python and I needed to pick up something quickly.

- 2,862
- 5
- 23
- 30
Because for many programming tasks C is simpler, and good enough. When I'm programming lightweight utilities especially, I can feel like C++ wants me to build in an elegant supersructure for its own sake, rather than simply write the code.
OTOH, for more complex projects, the elegance provides more good solid structural rigor than would naturally flow out of my keyboard.

- 37,399
- 13
- 80
- 138
Most of the significant features of c++ somehow involve classes or templates. These are wonderful features except for the way the compiler transforms these into object code. Most compilers use name mangling, and the ones that don't do something at least as messy.
If your system lives on its own, as is the case with many applications, then C++ is a fine choice.
If your system needs to interact with software not neccesarily written in C++ (most frequently in assembler, or Fortran Libraries) then you are in a tight spot. To interact with those kinds of cases, you'll need to disable name mangling for those symbols. this is usually done by declaring those objects extern "C"
, but then they can't be templates, overloaded functions, or classes. If those are likely to be your applications API, then you'll have to wrap them with helper functions, and keep those functions in sync with the actual implementations.
And in reality, the C++ language provides a standard syntax for features that can be easily implemented in pure C.
In short, the overhead of interoperable C++ is too high for most folks to justify.

- 975
- 1
- 8
- 7
-
4I'm very startled to hear this because I've written so many .DLLs in C++ that had extern "C" interfaces so they could be called from C or any other CLR language. Certainly you can't simply expose member function pointers, but it's really not much trouble marshal data for __cdecl calling. – Crashworks Jan 31 '09 at 02:31
-
2Actually, you can export templated code. It just requires non-templated function wrappers for every type you want to use to avoid name collisions. – Judge Maygarden Jan 31 '09 at 05:23
-
This is a problem with C++, but it's not a reason to use C instead. Whatever you'd have to do in C instead of templates and classes can already be done in C++ with almost the same code. – Pharap Feb 07 '23 at 17:48
Oh my, C vs C++, a great way to start a flame war. :)
I think C is better for driver and embedded code.
C++ has some great features that C doesn't have, but many of the object oriented features of C++ can cause monumental coding messes when people write code with non-obvious side-effects that occur behinds the scenes. Crazy code can be hidden in constructors, destructors, virtual functions, ... The beauty of C code is the language does nothing non-obvious behind your back, thus you can read the code and not have to look up at every constructor and destructor and so on. A lot of the problem is bad coding practices by SOME people.
My perfect language would be a combination of C99 plus a minimal subset of safer C++ capabilities that adds ZERO (or near zero) compiler overhead to the binary output. Perfect additions would be class encapsulation and naming concepts of data and functions.
One remark about "just use the subset of C++ you want to use": the problem with this idea is that it has a cost to enforce that everybody in the project uses the same subset. My own opinion is that those costs are quite high for loosely coupled projects (e.g. open source ones), and also that C++ totally failed at being a better C, in the sense that you cannot use C++ wherever you used C.

- 78,318
- 8
- 63
- 70
I haven't been able to find much evidence as to why you would want to choose C over C++.
You can hardly call what I'm about to say evidence; it's just my opinion.
People like C because it fits nicely inside the mind of the prgrammer.
There are many complex rules of C++ [when do you need virtual destructors, when can you call virtual methods in a constructor, how does overloading and overriding interact, ...], and to master them all takes a lot of effort. Also, between references, operator overloading and function overloading, understanding a piece of code can require you to understand other code that may or may not be easy to find.
A different question in why organizations would prefer C over C++. I don't know that, I'm just a people ;-)
In the defense of C++, it does bring valuable features to the table; the one I value most is probably parametric('ish) polymorphism, though: operations and types that takes one or more types as arguments.

- 7,680
- 3
- 44
- 51
-
3`++score`: Your statement *“People like C because it fits nicely inside the mind of the programmer”* is a very nicely stated one. Being able to program in a simple language where you know that what you see is what you get is a truly appealing property for a programming language. – tchrist Dec 21 '17 at 02:14
I would say that C gives you better control over optimization and efficiency than C++ and hence would be useful in situations where memory and other resources are limited and every optimization helps. It also has a smaller footprint of course.

- 4,355
- 5
- 20
- 12
-
1
-
1So the same C code compiled using a C compiler will be more efficient that if compiled using a C++ compiler? – Steve Kuo Jan 31 '09 at 01:16
-
1Years ago the Linux kernel could be compiled with gcc or g++, but g++ created slower code ( http://www.tux.org/lkml/#s15-3 under "Finally, while Linus maintains the development kernel ..." ). – Max Lybbert Jan 31 '09 at 10:00
-
I suppose I was thinking more along the lines of being able to control more of how your code is optimized in C over C++. Much like how a programmer using assembly language can fine tune his or her code more precisely than one using a higher level language. – Chris Feb 02 '09 at 19:15
There's also the approach some shops take of using some of C++'s features in a C-like way, but avoiding ones that are objectionable. For example, using classes and class methods and function overloading (which are usually easy for even C diehards to cope with), but not the STL, stream operators, and Boost (which are harder to learn and can have bad memory characteristics).

- 40,496
- 12
- 101
- 170
Because you're writing for a system where resources are tight (such as an embedded system, or some kind real bare metal code like a kernel) and you want as little overhead as possible.
There's a reason why most embedded systems don't have a C++ compiler - it's not that people don't want one, it's that cramming C++ code into that small a space is task that approaches impossible.

- 36,743
- 36
- 104
- 127
-
4Not really so much a problem of C++ itself as a language, but the pathological bloat that indiscriminate use of templates can cause. – Crashworks Jan 31 '09 at 01:15
-
2ecos is largely written in C++. There is no relation between the language (compared to C) and executable size (as long as you know what features to use). – user52875 Jan 31 '09 at 02:13
-
1"as long as you know what features to use". That's the point - the result of saying "well, we have C++, but we can't support half the language features for overhead reasons" is Symbian/C++, which confuses and angers both C programmers *and* C++ programmers... – Steve Jessop Jan 31 '09 at 02:30
-
1Agreed on all points. Our solution to "knowing what features to use" was to just use a C compiler and call it a day. Sure, we could have made C++ work, (which would have been really fun in a super-nerd kinda way) but we had a product to ship, and didn't have the time to worry about it. – Electrons_Ahoy Feb 02 '09 at 17:32
- Until some years ago the existing C++ compilers were missing important features, or the support was poor and the supported features vary wildly among them, and so it was hard to write portable applications.
- Because of the no standard naming of symbols it is difficult for other languages/applications to support C++ classes directly.

- 2,995
- 29
- 45
What C needed was a better preprocessor. cfront was one and thus born c++
I'ld use C, where the 'c++ as preprocessor' would not be okay.
I'm pretty sure, at the bottom of any well written c++ library/framework/toolkit, you would find dirty-old-c ( or static casts, which is same )

- 4,024
- 3
- 31
- 39