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
  • 31,939
  • 8
  • 101
  • 125
ern0
  • 1,035
  • 3
  • 8
  • 14
  • 2
    [Is there any reason to use C++ instead of C, Perl, Python, etc?](http://programmers.stackexchange.com/questions/29109/is-there-any-reason-to-use-c-instead-of-c-perl-python-etc) – chrisaycock Jan 23 '11 at 22:02
  • 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). – therobyouknow Jan 23 '11 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. – quickly_now Jan 23 '11 at 22:27
  • 5
    OOP is not the thing that makes C++ worthwhile. Templates are. –  Jan 23 '11 at 22:50
  • OOP isn't evil, it's a [hoax](http://programmers.stackexchange.com/questions/27388/what-prompted-alex-stepanov-to-consider-object-orientation-a-hoax-closed)! Just kidding ;-) – fredoverflow Jan 23 '11 at 22:51
  • @delnan Templating is a bit like hacking for me, but OOP is necessary, you can't build big systems without thinking in OOP (see Bruce Ekcel's books: Thinking in Java, Thinking in C++). – ern0 Jan 23 '11 at 23:30
  • 1
    @ern0: Templating is necessary for generic code (in C++; other languages have found other solutions) and for many other means of reducing boilerplate code. OOP, done right, is one way to manage complexity (there *are* others!), but language-level support is not strictly necessary (although still very nice) if you're using OOP as one ingredient, i.e. not as the main driving force. –  Jan 23 '11 at 23:36
  • This question gets asked every week. Close it. – Henry Jan 24 '11 at 00:08
  • 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. Jan 24 '11 at 00:29

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,224
  • 9
  • 64
  • 81
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
  • 1,999
  • 1
  • 18
  • 21
  • 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 Jan 23 '11 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. Jan 23 '11 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?". – cbrandolino Jan 23 '11 at 22:38
  • I don't understand the OOP **VS** procedural issue, because OOP is just a layer over top of the procedural, see C->C++ or C->ObjC. Sometimes we don't need OOP, sometimes we do (I prefer it, because the organization of the code is better with OOP). In a 10-line script we don't need even procedural. Some cases we need "more" than OOP. Other cases we need something completely different than the procedural/OOP line. – ern0 Jan 23 '11 at 23:40
  • 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. – cbrandolino Jan 23 '11 at 23:43
  • @cbrandolino I understand, but that's what the question is about: why? Why don't we use such a great feature, when it costs nothing? Why should we prefer using the procedural layer (prior to Basic-like gosub-return - I mean no parameters, no local variables), and why don't we prefer OOP? O.K., smaller tasks require no OOP (even smaller requires no procedural at all), but beyond a task size, we should use all the armor we have. We have a car, we don't go by walk (except to toilet). – ern0 Jan 23 '11 at 23:52
  • @Ern0, somebody might just don't like that approach. For a bigger project, he could chose to use some functional language and then add some C code for things such as graphics. Speaking in particular of C++, some don't like the way oop is implemented. – cbrandolino Jan 23 '11 at 23:59
  • I can understand, if someone wanna left out the OOP and, say, use functional, as you described, it's probably a good architectural decision. But writing a big system in C, with hundred of functions instead of splitting it to classes... strange. For me, OOP is coupled tightly with procedural, OOP *contains* procedural. Even in small projects, after creating the 10th function I reorganize them into classes, maybe just one class + organizer function. But here's a more trivial example: writing a PHP authentication subsystem without User class?! Never! – ern0 Jan 24 '11 at 00:13
  • 1
    @ern0: Functional programming also "contains" procedural. So clearly OOP can't be "the" (single) continuation of that. Additionally, looking at your examples, it seems as though you don't quite understand what OOP actually is. Using objects is *not* the same as using OOP. It's straightforward to write an authentication system that passes around an object that represents the user, without providing that object with any inherent functionality, so to claim that it can't be done without OOP is quite clearly wrong. – Anon. Jan 24 '11 at 00:26
  • 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 Jan 24 '11 at 02:17
  • 1
    Oh, and in many cases, C++'s 'extra' features aren't "free": there are lots of platforms where the needed runtime is prohibitive. – Javier Jan 24 '11 at 02:19
  • @ern0 "But writing a big system in C, with hundred of functions instead of splitting it to classes... strange" So writing Operating Systems is a strange concept to you? – MGZero Aug 10 '11 at 20:51
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
  • 10
  • 18
  • +1, but I don't call engineer, who didn't learn OOP. Nor programmer. – ern0 Jan 23 '11 at 22:20
  • 5
    @ern0, right. The kernel your OS is running on is made by weekend hackers. – cbrandolino Jan 23 '11 at 22:43
  • @cbrandolino Just because those kernel programmers use C to write kernels doesn't mean they are limited to only C. – Matthew Scharley Jan 23 '11 at 22:58
  • 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 Jan 23 '11 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. – cbrandolino Jan 23 '11 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). – Matthew Scharley Jan 24 '11 at 02: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. – Matthew Scharley Jan 24 '11 at 02:22
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
  • 923
  • 7
  • 16
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
  • 4
Andrea
  • 122
  • 4
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,815
  • 2
  • 35
  • 58
  • +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. – therobyouknow Jan 23 '11 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 Jan 23 '11 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 Jan 23 '11 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. – Mike Dunlavey Jan 24 '11 at 02:23