I disagree with the 'bottom lines' noted in the "Object oriented vs. procedural programming" writeups.<\p>
The statement that C++ is some percent less efficient than C makes me cringe when I read it.<\p>
It was noted in the article or one of the links that often C++ get's converted to C, during compilation, so it's just as efficient. That makes me cringe too!<\p>
It is true that in C++ there exist more complicated mechanisms that must be driven, such as the Vtable, and these things do require extra cycles. But in my 12 years of experience I've learned that these issues are usually not that big of a deal. <\p>
Usually, in a program that is percieved as "slow" and in need of optimizing, the code that is executing most of this time is localized to a limited number of routines that happen to be doing a lot of work. It is usually the case that in these few places, that code that is consuming the lyon's share of the CPU cycles can be optimized in C++ to run just as fast as it would have in C. <\p>
This will leave a ton of other code, that is consuming a little more CPU cycles than it should, due to it's C++ overhead. But all that other code doesn't get run much, so it doesn't count for much of the total time.<\p>
The statement "Procedural programming allows more direct control over the hardware it is being run upon." is very misleading. There is nothing that can be done in Assembly that can't be done in C or C++. While assembly may be more direct, in most cases it's a lot harder to write and less portable, that's why it's usually avoided like the plague, and if used, only used in specific subroutines where it is deemed to be most needed. C has no particular advantage over C++ when it comes to controlling hardware. And Procedurally implemented C has no advantage over Object Oriented implementations using C++. ( in my opinion of course... )<\p>
One need be very careful when having these debates to be clear when one is talking about a language, c -vs- C++, for example, or a software design approach, procedural -vs- OO for example.<\p>
I've been using C++ for years. But I choose a design approach every time I start a new project. The approach is often "mixed." I often end up with a very procedural looking main() that creates and uses several objects.<\p>
In my opinion it all boils down to your skill set. Some people don't have the skills to do OO design and implementation. If they try to use OO or some language they don't know it's going to suck, or at least take them a long time to do a good job.<\p>
Those who have the skills and can do a job efficiently using any design approach they know, will probably choose a design they think will work, and if you ask them if they used procedural or OO, they will have to stop and think about it because they won't know. All they will know is that they chose what seemed the best at the time.<\p>
Out of the 20 or so SW Engineers I know well, most of which learned OO on the job and are good at it, this OO -vs- procedural argument never comes up. It's commonly excepted that OO is the way to go, And in fact there is usually a strong pressure among this group to get the OO work, and not get stuck doing procedural stuff.<\p>
And if you look into the folks that are having this kind of debate, it's usually people who don't know OO well and don't have a significant amount of experience using OO yet. <\p>