Procedural Code vs OOP

[Swa]

Why would you want to copy/paste hundreds of lines of codes (in some cases) to do the exact same thing, and then, when you have to fix a logic error, sit and fix it (and remember where you used it) in all those places; when you could just define an object and put the logic in there and fix it once?



Maybe I'm just lazy and don't want to work "hard"

Most standard procedural languages today have means of avoiding code duplication. That is not what OOP languages were designed to deal with.

 

[Kosmik]

Don't read to much into this... but my experience is that most business applications don't lend themselves to OOP because they are CRUD pass-through systems.
As a result I have learnt to often move most procedural code to static helpers, instead of trying to glorify the container classes into a (domain) object model which it is not.

There's CRUD components and then theirs actually using the items those CRUD operations are feeding. Handling those as objects make a lot of sense.

2c.

 

[[)roi(]]

Semaphore posted some links about the OO C Linux Kernel. Also this.

Here's some bits about drivers. GTK/gnome. There are even jobs advertising for it (also). I have personally worked on OO C drivers in the past, and also on OO assembler since the platform was in development and had no C compiler, and also OO C on systems that had a C compiler but no C++ compiler.



Similarly, it could be said that given the huge number of different veggie burger/sausages options out there and the many different palates out there, making a generalization like this simply speaks to your level of inexperience.

Inexperience; is that with all things veggie burgers; if so, you've got me on that one as I must attest to not being able to differentiate between one cardboard vienna / patty or another

As to C / ASM and it's ability to faux OOP; sure (with a pimp) anything is of course possible.

You need only look at what was achieved with Obj-c to see what is capable with C & OOP, by using a combination of custom foundation extensions and pre-processing / custom compilation (arguably it's probably the more sacrosanct approach of adding OOP to C: certainly the most used);

As to native C & the OOP pimp, the mere fact that you can pimp your ride with a lot of effort certainly doesn't vouch for it's notability in the mainstream OOP arena... for example: many of the quoted code samples rely heavily on sacrificing type safety as a result of the pimp... that alone should be reason enough to bargepole the idea overall.

 

[cguy]

Inexperience; is that with all things veggie burgers; if so, you've got me on that one as I must attest to not being able to differentiate between one cardboard vienna / patty or another

In other words: "whoosh..."

As to C / ASM and it's ability to faux OOP; sure (with a pimp) anything is of course possible.

It's real OOP - just because it doesn't have the syntax doesn't make it faux. You create classes and objects, and reason about them as such.

You need only look at what was achieved with Obj-c to see what is capable with C & OOP, by using a combination of custom foundation extensions and pre-processing / custom compilation (arguably it's probably the more sacrosanct approach of adding OOP to C: certainly the most used);

As to native C & the OOP pimp, the mere fact that you can pimp your ride with a lot of effort certainly doesn't vouch for it's notability in the mainstream OOP arena... for example: many of the quoted code samples rely heavily on sacrificing type safety as a result of the pimp... that alone should be reason enough to bargepole the idea overall.

I don't think OO C is suitable for the "mainstream OOP arena", and I never said it was - you're arguing and disagreeing with a straw man of your own making. For the limited scope of system software, a few regulatory constrained environments, and new hardware, it clearly has its place.

Also, you're not sacrificing all your type safety - yes, with a simple OOP implementation you can cast any object pointer to any other object pointer, which most OO languages would complain about, but it requires a very visible explicit cast to do so. Your objects are still typedef'ed, and can't be used with incompatible methods, or passed as incompatible method parameters without an explicit cast. Your standard method of operation should work in a similar way to an OOP language, except that you need to cast your derived class to its base class when passing it to a method expecting the base class. There are support libraries like GObject that provide an API that will give you static and dynamic type safety.

 

[mister]

You guys are too serious for a Friday afternoon, smile for the weekend

View attachment 121943

AHHAHAHAHAHAA too true

 

[[)roi(]]

In other words: "whoosh..."



It's real OOP - just because it doesn't have the syntax doesn't make it faux. You create classes and objects, and reason about them as such.



I don't think OO C is suitable for the "mainstream OOP arena", and I never said it was - you're arguing and disagreeing with a straw man of your own making. For the limited scope of system software, a few regulatory constrained environments, and new hardware, it clearly has its place.

Also, you're not sacrificing all your type safety - yes, with a simple OOP implementation you can cast any object pointer to any other object pointer, which most OO languages would complain about, but it requires a very visible explicit cast to do so. Your objects are still typedef'ed, and can't be used with incompatible methods, or passed as incompatible method parameters without an explicit cast. Your standard method of operation should work in a similar way to an OOP language, except that you need to cast your derived class to its base class when passing it to a method expecting the base class. There are support libraries like GObject that provide an API that will give you static and dynamic type safety.

Sure with C being the root language; anything is possible. But as a language it wasn't innately designed for OOP, so whatever you shared (in it's current implementation context) should be considered nothing more than just another pimp.

Let me help to take this to it's probable conclusion: which really depends on how far you want to push this -- because being the root; we could in the same breath term OOP languages like C++ and Objective-c as also being nothing more than just another C OOP pimp; arguably they're the ones that are more widely used though (probably in large due to pre-processing, because their underlying C OOP enabling functions are arguably similar to GObject).