Do the concepts in Accelerated C++ Practical Programming by Example still hold up today?

Question

I was recommeded a book called:

Accelerated C++ Practical Programming by Example by Andrew Koenig and Barbara E. Moo Addison-Wesley, 2000 ISBN 0-201-70353-X

The basis of this book is that Object Oriented Programming is highly wasteful memory-wise, and that most source-code should not be written this way, rather that you should use all inline function calls and procedural programming.

I mean I know most programming books have about the same shelf life as milk, but if your coding a client/server application (database, server and all) (not a device driver or a video game) is it really worth the hassle of having un-maintainable code just for a speed boost?

Or is it worth it just to make the application run on a client's really old machine? Or to be able to run more servers on a single box?

Answer 1

Wow, no.

Modern C++ compilers are excellent. Massive memory usage is more of a symptom of a poor design or large memory data set. The overhead needed for C++ classes is minimal and really not a problem these days.

Object oriented programming is a way to write components in such a way that they can logically group actions related to a single concept (ie, all actions for a 'car' or all actions for a 'cat'). That's not to say it can't be misused to write spaghetti objects, but as they say, you can write COBOL in any language.

As a further example, it's quite possible and accepted these days to write for embedded software platforms with C++ and objects. The slight speed decrease and memory usage increase (if any) is repaid a thousand times over by increased maintainability and code usability.

Answer 2

I admit I have just skimmed that book, but it looks excellent - where exactly have you found this claim that C++ should be written in procedural way?

Answer 3

Think about the costs of an hour of a developer's time.

Think about the cost of an hour of CPU time.

And that being said, the performance loss by coding object oriented is absolutely neglectable. Particularly considering that when your program computes, it computes something - and that is probably much more dependant on the nature of the algorithm used than on whether or not OOP is in use.

Answer 4

I haven't read the book, but I have trouble believe that they wrote a book whose "basis ...is that Object Oriented Programming is highly wasteful memory-wise" (Full disclosure: Andy & Barbara are friends of mine).

Andy would never say the OOP is wasteful of memory. He WOULD say that a particular algorithm or technique is wasteful, and might recommend a less OO approach in some cases, but, he would be the first to argue that as a general rule OO designs are no more or less wasteful that any other style of programming.

The argument that OO designs are wasteful largely came from the fact that the EXEs of C++ "hello world" programs tend to be larger that the EXEs of C "hello world" programs. This is mostly because iostreams is larger the printf (but then, iostreams does more).

Answer 5

C++ and OOP are not inefficient per se, but it I have seen many C++ programs perform an operation in a less efficient manner than the equivalent C program. The biggest culprit is often due to lots of small memory allocations occurring due to newing individual objects rather than mallocing a whole bunch of them at once. Similarly, polymorphism and virtual functions are great, but they do incur an overhead that some C++ programmers are not aware of. Piecewise construction of objects can also be a lot slower than one dirty great memset of the aforementioned malloced array of structs.

My guess is that for most applications, on modern computers, this is not really an issue. Given that C++ also includes all of C as a subset, there is also nothing to stop you mixing and matching paradigms as situations demand. Newer heap handlers are also way better than the early MS efforts, and are a bg help.

Answer 6

The basis of this book is that Object Oriented Programming is highly wasteful memory-wise, and that most source-code should not be written this way, rather that you should use all inline function calls and procedural programming.

I would say this is a somewhat reductive summary of the book.

In short, to answer the title question, I would continue to recommend both the book and the concepts included therein.

I suspect that the advice is more along the lines that someone shouldn't create a class just to implement an algorithm, which I would say remains good advice.

Answer 7

Some of the answers are totally missing the point. OOP in C++ has many opportunities to be much faster than their C counterparts. I'll give the example from I think Effective C++ by Scott Meyers, which is that quicksort runs slower than C++ sort because the compiler is able to inline the function call easily in C++ whereas it is unable to do so in C due to quicksort being passed a function pointer.

Additionally, nothing about c++ makes it slow, unlike other languages, any slowness is purely library implementations or algorithm design.