The benefits of OOP?

[ikrana]

Originally Posted by bitter

You do realize that Python is a scripting language? And more than this it is not compiled, it's interpreted?
It's almost like comparing apples and bananas.

Agreed, but Python is used for a lot of non-scripting purposes too. For example:
https://en.wikipedia.org/wiki/List_of_Python_software

Python code can be compiled into python bytecode, though I will concede that the program in my example was being interpreted. My specific example was probably a bit unfair to Python, but considering that similar programs can be (and are) written in C/C++/Python, it's a valid comparison.

What intrigues me is that the code in a lot of the libraries for python is OOP code, but written in C, using things like function pointers.

[Spartak]

Originally Posted by Blappo

Maintainability and readability (although OOP doesn't guarantee either).

The performance and memory impacts are negligible compared to pure C code. If every ounce of performance and memory is needed then a lower level language (e.g. assembly) may be a better fit.

yes, our prof, which used to program DSPs for car audio systems in his career in the industry, told us story, that once they decided for whatever reason to redo their C code in C++. The result was, that the audio systems no more went online immediately after switching on, but with a delay of a few seconds. They needed that time just to initialize...

[MirekCz]

Originally Posted by Spartak

yes, our prof, which used to program DSPs for car audio systems in his career in the industry, told us story, that once they decided for whatever reason to redo their C code in C++. The result was, that the audio systems no more went online immediately after switching on, but with a delay of a few seconds. They needed that time just to initialize...

Nice story but it has got little to do with good programming.
Did their profile their application? Where was the bottleneck?

I was able once to optimize one function by a factor of 100 in 45mins using the same C language that the other programmer used. Does it show that C is good or bad?

[ikrana]

Originally Posted by Spartak

yes, our prof, which used to program DSPs for car audio systems in his career in the industry, told us story, that once they decided for whatever reason to redo their C code in C++. The result was, that the audio systems no more went online immediately after switching on, but with a delay of a few seconds. They needed that time just to initialize...

Probably has to do with the same sort of code writing as someone mentioned before - start creating classes for everything, because it's OOP. I find it very, very hard to believe that well written code in C++ would take seconds more than the equivalent C code. A few microseconds, maybe, but seconds just indicates bad programming (or apocryphal story )

[pmoses]

http://www.embedded-bits.co.uk/2011/...ux-boot-to-qt/

You can boot <1 second whole linux stack + qt app.

[Zizy]

Benefits of C++ vs C - there is none. C++ is almost always unmanageable piece of shit spaghetti code, losing clarity and too often also speed of C. C++ is good only if you want to do something quick and you plan to either forget about that code or write it nicely in something manageable.
Of course, you can use C++ to write pure C inside, that code is ok, but then you arent using C++, you are only using its syntax for writing C.
As far as OO goes - Java or C# or Python on the other hand are much simpler/faster/safer to write in, and are WAY easier to debug. Even if you adhere to all the best coding practices, C is unsuitable for anything large except if you are a masochist.

[Bitey]

BS c++ "is" about code reuse and scalable code, I take it you have never actually worked on huge critical systems, all the large million line+ stuff I have seen has been c++ or some highlevel stuff that hides the complexity in other ways.

C give you some nice bare(ish) metal performance, but you can not rely on a multiude of coders to create consistant and maintainable code for large projects, it breaks and is spaghetti-ised within a year of loseing/turning over your lead programmers. It can work with dedicated and long serving good programmers. (go linux kernel devs)

But most large projects live in a corporate world which rely rules like ISO standards to stop your worst coders (clock watching coporate drones) from fubaring everything.
The abstraction part allows the most complex code to be hidden from the people who should not touch it, but can use it via a nice abstraction layer of interface classes.
Doing that in c is not so easy.

These large corporates are also one of the places where they will run full run time type interfaces. That extra little switch you throw in a compiler which slows it down for normal code , but allows it to scale to corproate size and complexity.

[Lightning]

When you're first learning these things many people tend to see mostly just the positives or negatives until they've had time to experience both aspects. When I did my degree OO was "the big thing" and so functional programming and procedural programming weren't given much or any emphasis. Both have their place.

A wonderful example of where OO falls down is when people try to replace functional tasks with OO. The Ministry of Agriculture and Fisheries in NZ decided years ago to replace their Fortran code with C++ in an OO fashion. They got to the point where the smallest structure (actor) they could work with was a fish. This is of course, not OO's fault but the design process going wrong. There is no "object" here to modify via a common interface - they just want to know how many fish will be around next year and the year after.

That said, OO is generally very helpful for handling many day-to-day relationships. I heard it said that C got us to programs of over 100,000 lines of code, C++ got us over 1 million lines of code. I'm sure there are C programs of that size, but I think that it's generally true that code embracing OO can scale to larger projects more easily.

So, if you're only working on small projects - what you may see in the classroom for instance - you may never see the benefits of it. On the other hand even small projects can benefit from OO. OO is about code reuse and clarity, so anywhere that you have a need for a standard interface for complex data then OO can be very useful. For instance, I wrote a small program at work the other day to create a specific kind of plot. We'll be making two plots and sharing half of the data across the two. By loading from a database into an object I'm able to create some nice ways to get at groupings of that data (via a class method) in such a way that my external program doesn't need to know about how the data is stored - it just gets back a set of ids each time. I write that code to get the set once and I can use it without ever having to think about modifying it for things that aren't in my class.

If I were programming in a procedural way then I'd need to create a specific function for each data type in my data structure. If I make changes to my data structure then my function breaks. If I change my function then the rest of my code could break. While this is unlikely for a small program you have complete control over, in the real world most big programs are written by multiple programmers, so the idea of building an interface and working with that is a nice one.

Hope this helps,
Cam

[hyc]

Hm. 100,000 lines of useful, functioning code vs over 1 million lines of cruft. No thanks.

[ikrana]

Erm, I think he meant that you couldn't write a million lines of code in C, but you could do that in C++. Or I may have misunderstood that you misunderstood