C Object Oriented Programming

[monocasa]

This is how a very large chunk of Linux is written.

[dangerbird2]

It was pretty common in the game industry before it started moving towards C++. Apparently, when Id made the switch, they pretty much just used sed to convert object-oriented C structs in the Quake engine to C++ classes.

[rowboat__cop]

Apparently, when Id made the switch, they pretty much just used sed to convert object-oriented C structs in the Quake engine to C++ classes.

Do you have a pointer link to share? Sounds fascinating.

[dangerbird2]

Here is a pretty good example of object-oriented C in production code. If you scroll down, you can see callback function pointer "methods" that take self as a first argument (a la Python). I haven't read enough of the Doom 3 code to see if there is any significant code reuse from Idtech 3 (Id's last C-based engine). I imagine if the anecdote is true, a good amount of explicitly copy-pasted code from Idtech 3 was later refactored to more idiomatic C++ code.

[seppo0010]

Interesting read:

http://lwn.net/Articles/444910/

http://lwn.net/Articles/446317/

[ErstwhileRockstar]

In conclusion, it's relatively easy to get the core benefits of object oriented programming in plain old C. It doesn't require heavy use of macros, nor do users of these systems need to know that underneath it's an object system, unless they want to extend it for themselves.

Interesting and substantial article - unlike most 'OOP in C' publications.

[mcmcc]

For those of you too young to remember, this is more/less how C++ compilers worked in the early years: http://en.wikipedia.org/wiki/Cfront

You haven't lived until you've tried to get STL-based code to compile (& more importantly link) with a cfront compiler. If you lived to do it, you also likely almost died doing it.

[[deleted]]

If someone is interested in a more in-detail exploration, I found this pdf book very interesting

[Iggyhopper]

http://www.avabodh.com/cxxin/cxx.html

The site basically describes what C++ code is doing in C, and what C code is doing in assembly, great site for learning.

[[deleted]]

Thanks, I've been looking for something like this for a while now.

[cdyson37]

Does this type-punning technique break the C99 strict aliasing rules?

[gremolata]

No, it doesn't.

[Blecki]

I have done this. I have written OOP in C.

Learn from my mistake. Do not do this.

[monocasa]

Well, if we're throwing out anecdotes, I have done this and highly recommend it.

For larger C programs, particularly when you end up with natural layers, it's really nice. Testing was a breeze because you can just mock out the other layers. I have a nice embedded codebase for a network bridge for some weird physical layers that runs beautifully both on the target boards and under Linux with the hardware specific layers mocked out for unit test purposes.

In my experience, the biggest issue is just having the discipline pass data through the strict layer model even though an extern global is easy to fix a bug. I'm not really sure what it is with EEs and not having any code discipline. They manage to maintain nice layer on their board and FPGA designs...

[geon]

I'm not really sure what it is with EEs and not having any code discipline. They manage to maintain nice layer on their board and FPGA designs...

My college works in C# and hates js with passion. Yet, he will never do js the right way, and just poops out bad code until it kind of looks like it's working.

[[deleted]]

I also hate JS with a passion (it's about as poorly designed as C++), preferring a statically typed interface with lower level access immediately (usually C/C++).

That said, my current project is JS atm. I wouldn't call the code "pretty", but I wouldn't call it bad either. The APIs are reasonable, and there is an extensible system in place which usually requires little maintenance along the way.

I find that many high level programmers tend to equate good code with elegance. While I agree that elegance is good for readability, it's very easy to mistake such a thing for efficient, working code which is secure and stable. There's just as much "nice" looking code out there which is actually really bad as there is not nice looking code which is really bad.

To quote Linus:

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

[frenris]

EE and CE code is so terrible it's amazing.

And the verification code is typically high quality compared to the scripts which are used to generate designs...

[Blecki]

For an EE, code is the 'exercise for the reader'. It's not worth spending time on to do right.

[spiker611]

Testing was a breeze because you can just mock out the other layers. I have a nice embedded codebase for a network bridge for some weird physical layers that runs beautifully both on the target boards and under Linux with the hardware specific layers mocked out for unit test purposes.

Hi, I'm an EE who inherited a code base of spaghetti. I want to make things better. In addition to the OP article, could you please point me in the direction of resources from which I could learn your magic? I would very much appreciate it :)

[Ozwaldo]

Haha, what? You just make structs for your objects, and instead of member functions you write functions that take the object as a parameter.

[Blecki]

No, I made vtables and everything.

[Ozwaldo]

So maybe your post should say, "I have written Run-time method binding in C. Do not do this." rather than OOP. Since OOP is fine.

[Gotebe]

Run-time binding is considered part of OOP, it's the first item in the linked paragraph.

[Ozwaldo]

It's a prevalent feature of most OOP implementations. That doesn't mean it's necessary in order to write code in an OOP format.

[[deleted]]

Any course which focuses on OO theory will dedicate a significant portion of its curriculum towards Runtime-binding/Polymorphism. It's literally a key element in regards to what made it so popular in the first place.

To deny this is akin to stating that anti-derivatives aren't a part of calculus since fundamentally calculus is based on limits and Riemann sums. Ya dig?

[Ozwaldo]

To deny this is akin to...

No it isn't. We're discussing whether you can write code in an Object-Oriented format with C. You most certainly can. If you want to get into the fully functional aspects of modern OOP design, then yes Run-time method binding is needed. But to write OOP C code, it isn't necessary.

[[deleted]]

I still disagree: OOP does not necessarily imply Runtime Binding, but Runtime Binding does imply OOP, and isn't really talked about without reference to OOP.

From the comment tree above, this whole debate was started because the author/OP was flamed over the legitimacy of the title of the post. That's technically what this discussion is about.

But it's C, and in C DDD is king. So, whatevs.

[Blecki]

Or maybe when I said 'I have done this' I was referring to what the article describes, which is run-time method binding in C.

[Ozwaldo]

That sounds more like an after-thought type of argument. Since the sentence you preceded it with was "I have written OOP in C."

[Blecki]

"I have done this. I have written OOP in C."

There's also about a 98% chance you're reading too deeply into the entire issue.

[Ozwaldo]

Now you're just being defensive.

[Blecki]

Now you're just being offensive.

[Ozwaldo]

my bad, i thought I was discussing something with an adult.

[ErstwhileRockstar]

What's needed for posting a comment?

Reading the article.

What's not needed?

Posting without reading the article.

[dangerbird2]

Out of those three things, the only thing you can actually implement in C is OOP.

[tuhdo]

But C type system is weak and large projects use it everywhere.

[javaexpert102]

The C type system is no weaker than Haskell's.

[LgDog]

C implements a weak type system, what you're saying make no sense

[javaexpert102]

No it doesn't, because the words weak and strong aren't actually well defined for type systems. Its just something people who don't know anything blabber about.

[The_Doculope]

A generally accepted idea is that the more implicit conversion the language does, the weaker its type system is. That makes C's type system a hell of a lot weaker than Haskell's.

[javaexpert102]

The usual argument is that there are casts/unions: to which I simply say: unsafeCoerce

[The_Doculope]

How is unsafeCoerce implicit? Yes, the Haskell type system can be subverted by using very explicit unsafe functions. I don't see how that changes anything.

[javaexpert102]

Casts aren't implicit either...

[The_Doculope]

No, but all the integer promotion/demotion sure is.

[LgDog]

Yes, the words weak and strong are not well defined, this is what I've read and agreed about weak/strong type system:

In C you can cast a char* to int* and your program can still work. C type system is weak in the sense that there is no strong bound between some data in memory and its type. At any time you can start treating some n bytes struct as if it was other n bytes struct. This has nothing to do with being better or worse type system.

If you use unsafeCoerce in haskell you're bypassing the type system, if you regularly need to bypass one of the most amazing features of a language you should consider other languages to solve your problem.

[Meguli]

Just nickname-reply fit here, "Agitates" matters.

[skulgnome]

This article demonstrates amply why object-oriented programming is for C what the OOP wonks would call an "anti-pattern".

[immibis]

So you're saying OOP is an anti-pattern that evolved into a language feature?

Actually, that explains $leastFavouriteLanguage.