I can't imagine that there's any reason not to use the OOP features of C++. It's is just as fast as C, and - what's more important to me - it's transparent, just as C. (I mean "transparent" that I know, what is my source is compiled to. Or, I think, I know.)

Is there any reason not to use the power of OOP in C programming?

I accept only embedded systems or other restricted platforms as exceptions, where no such memory management is available, which is required by C++. I also accept operating system development. Or programs started writing before C++. Okay, that's all.

UPDATE: the question is just about C vs C++, not C/C++ vs other languages. I'm using C/C++ just in "final case".

  • 2
  • 1
    +1 Fundamental implementation question, particularly for embedded real-time systems (e.g. consumer electronics, control systems) and semi-embedded (i.e. kiosks, mobile phones, game consoles) where resources (CPU time and RAM are not so abundant as on a desktop). Commented Jan 23, 2011 at 22:10
  • 1
    Picking a point: C++ won't always be as fast a plain C. Every object has its "this" pointer, and inheritance in particular will, under the hood, require one or more dereferences to be made. There will likely be a performance penalty, however this might be small. But do enough of them and you'll pick the difference. Commented Jan 23, 2011 at 22:27
  • 5
    OOP is not the thing that makes C++ worthwhile. Templates are.
    – user7043
    Commented Jan 23, 2011 at 22:50
  • 8
    @ern0: You don't need OOP to build big systems, and anyone who claims that is closed-minded. Modules, packages, namespaces - there are plenty of mechanisms for organizing source code heirarchies, and in fact, if you're using a Class purely to organize common functionality (rather than functionality on common data), you're not using OOP. Perhaps you should try to step outside the bounds of languages you currently know? Learn Haskell, Prolog, Lisp, anything with a radically different paradigm to what you're used to. It will make you a better programmer.
    – Anon.
    Commented Jan 24, 2011 at 0:29

6 Answers 6


My favorite reason for not using C++ is that C has a de facto standard ABI on most platforms. In other words, because there's no name mangling, etc., you can usually link code compiled with two different C compilers. With C++, good luck because you'lll need it.



  1. You just don't like OOP - it's a paradigm, after all, not a dogma;
  2. You need to write a small (in terms of lines) application with a potentially huge compile time;
  3. You don't like/need some of the features of C++.

After all, they are two different languages with a mostly shared syntax. You just chose the one that better fits your needs/taste.

  • 2
    OOP is not a Facebook page, which you may like or not like. What if someone doesn't "like" procedural programming? Local variables? Nonsense. OOP is a technique/paradigm, which is an organic way of the evolution of (procedural) programming languages. Wanna go back to BASIC? GOSUB-RETURN?
    – ern0
    Commented Jan 23, 2011 at 22:24
  • 26
    @ern0: OOP is not the only way to program, not by a long shot. In fact, for many problem domains, wrapping all your functionality in objects is quite clearly the wrong choice. Simply treating objects as data, and performing operations on that data, is a perfectly valid alternative, and anyone who espouses OOP as the "one true style" is as bad as the people starting religious wars over brace positioning.
    – Anon.
    Commented Jan 23, 2011 at 22:30
  • 7
    @ern0: Sorry, but object-oriented and procedural describe two different characteristics of programming languages. Object-oriented is not necessarily an evolution of, nor the only evolution of, procedural programming. Saying "object oriented is the evolution of procedural, wanna go back using basic?" is like saying "OCaml is the evolution of functional, wanna go back to Lisp 2?". Commented Jan 23, 2011 at 22:38
  • 2
    @ern0, what I was trying to say is that OOP is not necessarily a layer on top of procedural. And I sure know we don't necessarily need it, or not always - that was ~ the point of my answer. Commented Jan 23, 2011 at 23:43
  • 2
    @ern0: it's the other way around: OOP is a subset of procedural. And, as i never get tired of repeating: OOP is a design style, not a language feature. On the personal side, as much as I like C++, I feel more relaxed writing C. (what can I say, I'm a minimalistic at heart). But the final answer is how cbrandolino put it: they're two different languages, each one is best on different situations. (even if the advantages of C are mostly cultural and not featurewise)
    – Javier
    Commented Jan 24, 2011 at 2:17

A legitimate reason I was given by a prior employer:

You work with engineers who didn't learn OOP and your manager would prefer they be able to understand your code without having to.

  • 5
    @ern0, right. The kernel your OS is running on is made by weekend hackers. Commented Jan 23, 2011 at 22:43
  • 1
    Hmm, I carefully word the answer so as not to imply the engineers couldn't learn OOP, and people argue about it anyhow. :/
    – mootinator
    Commented Jan 23, 2011 at 23:04
  • 3
    @Matthew Scharley, I know. It's just that I don't see why one should know OOP to be defined as an engineer/programmer. Kernel programmers might or might not know oop, but not knowing it/caring about it won't make them less cool. Commented Jan 23, 2011 at 23:05
  • 2
    @cbrandolino I agree about OOP in particular, but I draw an analogue to a builder. A good builder knows how to use a hammer, a trowel, a saw, a screwdriver, etc. A good programmer knows how to use OOP, procedural programming, a few different languages, etc. A good programmer has a few different tools in their belt, not just one (C in this instance). Commented Jan 24, 2011 at 2:21
  • 2
    @mootinator, a good lesson in life. There's always going to be someone who misreads/misunderstands what you write/say. Or attach their own more extreme ideals to it. Commented Jan 24, 2011 at 2:22

Short answer: it depends on what features of C++ that you use - AND - whether you have enabled the compiler to use them.

Specific example to support above example: Exception Handling in C++: with the try, throw, catch statements. Some compilers have a command line option to enable or disable support for exception handling - i.e. code with try throw catch will compile. Enabling support for exception handling, even without using it, can cause the compiled binary to increase by up to a third in size compared to when it is switched off. So if memory for holding your program is scarce and you don't use exception handling or can find another way to report errors, then turn off this in the compiler.

Your question applies particularly for embedded real-time systems (e.g. consumer electronics, control systems) and semi-embedded (i.e. kiosks, mobile phones, game consoles) where resources (CPU time and RAM are not so abundant as on a desktop). However, I worked on 2 embedded real time projects where part of the software stack was written in C++, one was in optical drive firmware (DVD/CD burners) and the other was fibre-optic multiplexor control software.

I agree with @mootinator that it depends on who you are working with because it could impact the delivery of your project if your fellow team members need to get up to speed with C++.

C++ can bring benefits of reuse and maintainability via the Object Oriented Programming concepts that it provides.

So you might want to research carefully the performance (speed and memory) of C++ in your chosen field. Once you are confident that you can still use C++ following this research, you then need to implement and test regularly to confirm that the performance needs of your project are still being met, so that there are no surprises.


Of course C++ is not evil (even though I've seen it invite abuse). However, there are some cases where I stick to C.

C++ compilers mangle names, and they tend to have a lot of library support for memory management, serial I/O, class libraries, and so on. All those things have value if I need them. Sometimes I don't want all that, and I prefer something closer to the "metal".

  • +1 for "closer to the metal" - I like that - that's a different but valid way of talking about how low level one can go with a language. Commented Jan 23, 2011 at 23:15
  • I've written a dataflow system in C++, which use only stdlib and pthreads, it runs on minimal Unix systems (e.g. on NAS, SBCs), it requires no special libraries.
    – ern0
    Commented Jan 23, 2011 at 23:22
  • 1
    I like "closer for the metal", too, but I found C++ doesn't step away from the metal. All the hardcore C stuff can be used in C++ and OOP.
    – ern0
    Commented Jan 23, 2011 at 23:44
  • @ern0: I know what you mean. There are times when classes are what I need and it's a pain doing them in C. At the same time, I've never taken a shine to all that cout stuff (and all its library support). I suppose that makes me a minority of one. Commented Jan 24, 2011 at 2:23

The answer could depend on the team and the project that are going to use C or C++.

I think that here you can find a good review of the benefits of plain C vs C++. The author argues from the embedded developer point of view, but shows practical cases where C "wins" over C++ in terms of performance, maintainability and transparency. The same author is the author of the C++ FQA, a collection of C++ bashing articles that are, nevertheless, quite informative even for a C++ enthusiast.

Another aspect to consider are the idioms typical of C++. Some of them may be pesky while not being actually related to OOP in general.

An example of that are constructors, which don't return values but allow for parameter passing and initialization lists. The author of above argues that constructors and initialization lists create more problems than those they ought to solve and in lots of coding guidelines it is in fact advised to not use complicated constructors with lots of parameters, but to use simpler ones, even just the default constructor, and provide the user with appropriate initializations routines. This is, for example, the approach taken in Ada95 and beyond, where objects have, if any, only a constructor with no argument, akin to the default constructor in C++.

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