7

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

Adam Lear
  • 32,069
ern0
  • 1,045

6 Answers6

15

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.

dsimcha
  • 17,284
9

Cases:

  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.

cbrandolino
  • 2,009
  • 1
  • 18
  • 21
6

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.

mootinator
  • 1,280
6

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.

therobyouknow
  • 933
3

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

Wilfred Hughes
  • 103
Andrea
  • 122
3

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

Mike Dunlavey
  • 12,905