C++ vs C - Why write Object Oriented Software?

[Chris Meech]

James, It is my opinion that C vs C++ is not a non OOP vs OOP comparison. One can apply an OOP methodology to developing in C just as one can apply an OOP methodology to developing in C++. The advantage is that the C++ language has features that make the development much more practical and easier. The best book that describes this in detail, is one by Roger Sessions. It describes class development using C and C++ and very clearly shows the benefits. I'm sorry I don't have the title at the moment, but I'll try to post it later today. And you are right, this is no easy question. Chris Meech PS. I would of thought that most C programmers would have been attracted to the higher salaries of the C++ programmers :)

[Jim]

You might mention that many of the new designs (at least in GNOME) where C is used, are very much patterned after OOAD, and try to emulate OO as much as possible within the language constraints of C. In fact they (the folks working on GNOME) have even goe so far as to specify an IDL like language where they define their "classes" and then run this through a pre-processor which generates the "OO" C code stubs, which they then fill in. You could then explain that C++ allows for the same thing but makes the whole process a little easier to do. However on the other hand, having used C++ alot, and met a few Unix guys myself, it sometimes is hard to justify the effort, especially if there is so much legacy, and let's face it a C compiler generally blows the doors off a C++ compiler with fewer issues involved (at least in my experience). Maybe you'll have a better time selling the OO design effort rather than trying to push C++ too hard

[Jim]

You might mention that many of the new designs (at least in GNOME) where C is used, are very much patterned after OOAD, and try to emulate OO as much as possible within the language constraints of C. In fact they (the folks working on GNOME) have even goe so far as to specify an IDL like language where they define their "classes" and then run this through a pre-processor which generates the "OO" C code stubs, which they then fill in. You could then explain that C++ allows for the same thing but makes the whole process a little easier to do. However on the other hand, having used C++ alot, and met a few Unix guys myself, it sometimes is hard to justify the effort, especially if there is so much legacy, and let's face it a C compiler generally blows the doors off a C++ compiler with fewer issues involved (at least in my experience). Maybe you'll have a better time selling the OO design effort rather than trying to push C++ too hard

[Stan 0]

OOP is not a cure-all. Even though I am a strong advocate of the method, it is not an answer to every class of programming problem. Given enough time, the problem at hand should be evaluated to determine if the added complexity of an OO architecture is necessary. In addition, there is no problem that occurs with procedural code that can not also occur with OOP, especially with C++, since C++ is NOT a true object oriented language. OOP as a cure for spegetti code? Give me a break, some of the worst speggetti I have ever had to navigate was, on the surface, pecfectly formed OO code. The greatest argument in favor of OOP is extensibility and maintenance of a code set, via polymorphism, as well as, if properly done, code reuse. Existing code does not need to be modified to manage a given set of data, the functionality acting upon that data can be added via inheritence. Behavior of the application can be modified more safely and quickly with an OOP design. Good OOP also represents a more robust way to manage large, complex data sets. If all your data is global to a huge number of procedural functions, the management of that data is far more problamatic than if the data is carefully encapsulated in logically designed classes. With procedural code you WILL reach the upper limit of complexity far sooner than you will with good OO code. In 12 years of doing OO, however, I must say that I have never actually seen a true OO design (in C++). Every app I have ever taken a close look at violated the paradigm in any number of significant ways

[Erik Funkenbusch]

To be perfectly honest with you, I'd say there are probably very few merits in your environment. OOP is a way of life. A philosophy. A way of looking at everything you design and code. If not everyone is "on board" then you'll run into all kinds of problems. For instance, one client I have had, had a few programmers that refused to use anything other than global variables rather than encapsulation into classes. This made it very difficult for the rest of the team to work effectively, and caused more problems. The key to good software design is consistency, no matter what method you use. If you can't be consistent in a new approach, it's probably wise not to introduce it. Set in their ways developers will sabotage any efforts you make to create good OO code.

[Ravi Bhavnani]

Stan raises 2 very good points: (1) The greatest argument in favor of OOP is extensibility and maintenance of a code set, via polymorphism, as well as, if properly done, code reuse. (2) OOP is not a cure-all. If one looks at the evolution of programming languages over the past 50 years, we'll see something that goes like this: - machine code (processor dependent) - assembly language (processor and vendor dependent) - high level language (eg: Fortran IV) - structured high level language (eg: Pascal, C) - object oriented language (eg: C++) Each step of the way, computer scientists recognized a need for something that would solve an existing problem. In my opinion, a language like C++ that lets you formulate solutions in an object oriented sorta way helps solve the problems of extensibility, code reuse and maintainability. I prefer to work in Java (and soon C#, perhaps) which is pretty object oriented (though not perfect) and has the added benefit of including design patterns as part of the language definition. Imho, proven design patterns go a long way in helping programmers craft reusable solutions and solutions whose correctness can be more easily verified. Also imho, program maintenance and scalability are one the biggest hurdles the industry faces. I'll end my missive by reiterating Stan's comment: OOP is not a cure-all! /ravi "There is always one more bug..." http://www.ravib.co

[Jason Clarke]

Must it be only in terms of Why OO? There are other solid reasons for choosing C++ over C that could be stated that have nothing to do with OO, but which maybe more 'acceptable' to a group of C programmers. For example: C programmers could use facilities like the STL string class or the STL vector knowing very little about OO - but these could bring significant benefits in simplicity/reliability of equivalent C code. Through the use of templates it is possible to implement generic functions that are far simpler (and potentially more efficient) than their C counterparts. There are reliability benefits, such as type-safe linkage. And the skill-set/salary point mentioned before is important. Most software developers like the chance to update their skills

[Bill Gates 0]

I moved from c to c++ using mfc now im back using c and the plain sdk. c++ allows encapsulation or information hiding which allows abstraction and reduces complexity. duh! my experience is that it can foster ignorance through the use of libraries and a dont care approach to coding style etc. using c means you have to know what you are doing. C++ is probably great for those monolithic trillion lines of code projects where they know it will all be done again. Look at java javascript active-x com, dcom , c# mfc, atl the list is endless all proprietary hook ups using oops techniques, then they get superceded and dumped bye bye mfc

[Stan 0]

Valid observation, however, the entire point of code reuse is so that not everyone must understand every single line of code in a large project. Being able to plug a module into a project your responsible for without being overly concerned about its internal behavior, is a good thing, not a bad thing. Although I detest the comparison of software engineering to electronics engineering - one could ask if the electronics engineer is worse off for not needing to redesign every circuit in every device he designs rather than shoping around for the right IC board. He must still know how and when to use it, its operating parameters etc. No less the Software engineer judiciously integrating pre-designed software components into his work. That SHOULD be the goal the Software engineering world strives for and OOP is one technigue for achieving it

[Vimal]

C++ is more of concepts than as a language. It's a methodology of Programming. Using Data Encapsulation, we achieve Data Abstraction. Because of this Data Abstraction, we would think of problem in terms of real-life objects ( the way we are used to more ). This enhances your chance for better solution. Moreover, It's better to have 'Divide and Conquer' - better to build entities which are self-supporting - encapsulating data along with methods. -- Don't look C++ as a language - its' concept --