Recently, I finished reading K&R with its, almost all, exercises and examples. I was planning to move to \"Accelerated C++\" that I came across Axel Schreiner\'s book OO
Implementing OOP in C, is it really used? Or its just for mental exercise?
Yes, it's really used, but unsurprisingly, it's not as common as OOP in languages that were designed for it.
Are their any existing C projects that use OOP?
I can remember using a couple:
When it is a good idea to use OOP in C?
Some problems are very well modeled by OOP. GUIs, for example, are often designed with inheritance between window types, using polymorphism to override and specialize behavior.
You should use OOP whenever your problem has a beautiful OOP solution. With the footnote that you shouldn't stick 100 lines of OOP code in a 15000 line project, just because it's "kewl"! :)
Should I invest my time in it?
That really depends on what you plan to do with it. I'd never advocate not learning anything - it's great to get exposure to how, why and when to use it. It's great to see a language that wasn't designed for OOP support OOP. You read the book, so I assume you have some affinity to C and interest in OOP. Give it a shot, maybe throw together some GUI applications in GTK+. On the other hand, if you're looking to become the next design patterns master web developer, it's probably not the best approach, you may consider other languages that are more focused toward that area.
So what would you suggest?
I'd suggest you use the best tools at your disposal that fit the problems you're trying to solve. Decide what problem you're going to solve. A GUI desktop app, a web server, a game, a cmd line utility... once you decide on your problem, you'll be able to better decide which technology fits for developing a solution. I've found that you can't really master anything with "toys", so you need to be doing something real.
OO is used in C as often as needed. Generally I don't agree with the opinion that one cannot do OOP in C, as soon as you provide set of functions that operate on a given type you have OOP. Take for example, you decide to create a data structure. If you provide functions to create, add, remove, and find elements of the data structure it's OO. Generally other languages provide syntactical sugar by automatically implying an instance variable and scoping in various properties of that instance automatically.
It can be, but without the destruction-time function-calls provided by other OOP languages, it's not that useful. In addition, if you need OOP, there's always C++, where your code is virtually instantly portable to it.
There are people who say you can write object oriented code in any language, and there are also people who say you can write horribly unstructured code in any language.
Real "OO" language provide you with a handful of mechanisms for implementing OO design: The languages have built-in concepts for object and/or classes, for encapsulating code with data, for inheritance and so on. C has essentially none of this, but there's nothing stopping you from doing OO programming in C, given some techniques and self discipline (as your book surely tells you).
But would you want to?
My opinion is this: If you're just learning to do OO programming, it might make more sense to learn this while being "held by the hand" by a language which already deeply incorporates the concepts. A well-structured, simple and interactive language would be nice for this: Given a free choice, I'd recommend Ruby, Python or Groovy. Given a language with built-in OO "magic" it becomes very obvious when you're doing OO things and when you're just being structured, disciplined and well-organized. There may also be stuff to be learned when moving from C to another language: The commonalities, the differences.
Some people would recommend learning C++ as the natural OO progression from C. I don't wholeheartedly support this, because I consider C++ a rather ugly bolting-on of OO capabilities on a language that was already more "practical" than elegant. When moving from "standard" C programming to OO programming, I think a programmer should consider moving away from direct manipulation of pointers, for example, and certainly I'd find it burdensome to have to manage memory for my data. Modern OO languages automate this so that a programmer has more brain cells left over for higher-level tasks. The appeal of C++, of course, is raw speed. Because it can drop to the same near-metal level as C, it is usually the "fastest" of OO languages.
All that said: If you have a big project where the required language is C and you want to use and practice OO techniques, then by all means go ahead! If not, you might benefit from learning OO in an environment that encourages and supports this, and perhaps later coming back to C with your knowledge of OO. The techniques taught in the book will make sense to you then, and you'll be in a better position to decide if you really want to do this in C or in a "real" OO language.
I've had experience with several advanced C projects which make at least some use of OOP. The most well known is the Linux kernel.
The kernel is entirely C (except for platform specific pieces in assembly for hardware interfaces).
The kernel makes heavy use of structures with function pointers in many places. The first that comes to mind is file systems. Drivers fill in the file_operations struct (as well as many others) with callbacks to their specific implementations.
The kernel also makes a lot of use of goto
statements which in some contexts can be thought of as rudimentary throw statements leading a label at the end of the function to do some clean-up and exit. (Though they do also use goto
for a lot more than just error handling, and it is also only used for "exceptions" within a function, not for passing them outside.)
Maybe see the ooc-lang project mentioned here:
http://attractivechaos.wordpress.com/2009/09/20/oop-in-c-dont-go-too-far/