Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OOP in C

staff.washington.edu

Post reply on HN
Print view View original

91–100 of 149 posts

Re: OOP in C

#91

Post by lll-o-lll »

rramadass wrote: post #71
lll-o-lll wrote: post #19

Earlier quoted context omitted.

Yes, the article is terrible as it does not show any polymorphism. Also, yes, doing genuine polymorphic OO in C ends up horrible because you invent a new language. (Source: many years working on a truely evil code-base of OO C. Originally the work of one twisted genius. Brilliant, but evil). OO was just a failed paradigm anyway, I’m amazed anyone would try and shoe-horn it into C in the modern day.

https://news.ycombinator.com/item?id=34220101

This isn’t a religion. I really don’t see what is so controversial about suggesting OOP has clearly failed on the majority of its original stated goals.

That’s not to say that nothing has been salvaged from the wreckage; languages like Rust are a great example of retaining what actually was useful.

Re: OOP in C

#92

Post by morby »

askvictor wrote: post #3
johndoe0815 wrote: post #2

A whole book on this topic was already written in 1993 by Axel-Tobias Schreiner. It seems to be freely available nowadays: https://www.cs.rit.edu/~ats/books/ooc.pdf (edit: link updated to point to author's website)

I remember having a book on the shelf through the 90s entitled 'Object Oriented Programming in Macro Assembler'

This sounds like a nightmare

Re: OOP in C

#93

Post by _0w8t »

flohofwoe wrote: post #89
_0w8t wrote: post #87

I recently needed to write C code to interface with a COM library on Windows. While Microsoft fully supports it, the result is very foreign compared with typical C code. Surely in C one does use tables of function pointers to implement some aspects of OOP. However, a good library limits it and rather exposes some structs instead of requiring multiple virtual methods calls to archive a similar effect.

It depends a lot on the wrapped APIs, for instance D3D11 is a struct-heavy API exposed via COM and totally fine being used from C code (instead of C++), even works nicely with C99 designated init for initializing the input structs.

My experience was with MFC, that uses methods even for basic getters.

Re: OOP in C

#94

Post by a-user-you-like »

asveikau wrote: post #81
alerighi wrote: post #68

Earlier quoted context omitted.

To some problems that are almost always seen in the academic world but I've yet to see in my daily job. Inheritance (from implementation, I've nothing against implementation of interfaces or inheritance from abstract base classes) has a ton of problems, more importantly the fact that it makes the code more difficult to understand and to evolve. Composition on the other hand is something more natural, even if we think…

It's strange that you seem to be an absolutist on this topic. What is wrong if inheritance is an elegant solution to a relatively small number of problems? Historical overuse of inheritance doesn't take away from that.

What problem is left? UI? React is showing composition wins there too.

Re: OOP in C

#95

Post by Koshkin »

AlbertoGP wrote: post #45
antirez wrote: post #12

C required the simplest form of OOP, but who standardizes it decided to deny the feature to the language: the ability to have callable structure methods (function pointers) with explicit "self" pointer. Not even constructors/destructors. After all it's C, and you can write list->init() and list->free(). This simple form to bind data and the functions operating on such data would make many codebases better.

I made a pre-processor [1] to add similar features to C, and after reading your comment I’m thinking that it would be simple to add a setting/#pragma to do these transformations: list->init(); → list->init(list); list.init(); → list.init(&list); [1] https://sentido-labs.com/en/library/cedro/202106171400/#back... I normally avoid the function pointer overhead, which can be done with _Generic: #define append(VEC, START…

> I made a pre-processor

You followed the path of C++.

Re: OOP in C

#97

Post by isityouyesitsme »

lll-o-lll wrote: post #90
isityouyesitsme wrote: post #43

Earlier quoted context omitted.

I don't think OOP has failed at all. It has become the foundation of all reusable code in every language. What failed was the idea that internal state can be managed and shared with derived classes. The key to OOP is extracting the idea of types/concepts into interfaces that may have different implementations. You don't even need a language that supports polymorphism as a first-class concept in order to do this, thou…

Eh, this is a very separate debate. You don’t need OO for modularity. This should be obvious. You need an API/Contract and for re-use you need a “module” (such as a dll or a web interface). For example something like: int CreateTheStatefulThing(blah* thing); DoStuffWithThing(blah* thing); void CleanUpThing(blah* thing); To suggest OOP is the foundation of reusable code is simply wrong.

You are reading in to what I wrote something I did not say.

I said that "OOP has become the foundation," not "OOP is the foundation." There is a very big, historical, fact-based distinction between those two statements.

Modularity and reuse are completely different things. A highly modular codebase is more amenable to write reusable code, but many modular systems have been written with very little concept and code reuse.

Of course there was a measure of reusable code before OOP was a more formalized language for discussing it. But to say "you can do these things without OOP" is like saying you don't need structured programming to write maintainable systems. And it's like "ok, but you're still using "if," possibly "return," and you know... functions." Essentially the exact same ideas that the paradigm gave formal language to.

I think people who say that OOP wasn't responsible for the understanding of modern paradigms haven't read much of the theory behind it and have hyper focused on the poor series of books and articles that came out from the 1980s through about 2010 that encouraged hidden state ownership and inheritance of state.

Re: OOP in C

#98

Post by billfruit »

antirez wrote: post #12

C required the simplest form of OOP, but who standardizes it decided to deny the feature to the language: the ability to have callable structure methods (function pointers) with explicit "self" pointer. Not even constructors/destructors. After all it's C, and you can write list->init() and list->free(). This simple form to bind data and the functions operating on such data would make many codebases better.

But how do you tackle creation of objects, call malloc everytime?

And how do you for example, create an array of objects, like one can easily do in c++?

Re: OOP in C

#99

Post by [deleted] »

billfruit wrote: post #98
antirez wrote: post #12

C required the simplest form of OOP, but who standardizes it decided to deny the feature to the language: the ability to have callable structure methods (function pointers) with explicit "self" pointer. Not even constructors/destructors. After all it's C, and you can write list->init() and list->free(). This simple form to bind data and the functions operating on such data would make many codebases better.

But how do you tackle creation of objects, call malloc everytime? And how do you for example, create an array of objects, like one can easily do in c++?

[deleted]

Re: OOP in C

#100

Post by AlbertoGP »

Koshkin wrote: post #95
AlbertoGP wrote: post #45

Earlier quoted context omitted.

I made a pre-processor [1] to add similar features to C, and after reading your comment I’m thinking that it would be simple to add a setting/#pragma to do these transformations: list->init(); → list->init(list); list.init(); → list.init(&list); [1] https://sentido-labs.com/en/library/cedro/202106171400/#back... I normally avoid the function pointer overhead, which can be done with _Generic: #define append(VEC, START…

> I made a pre-processor You followed the path of C++.

> You followed the path of C++.

To some extent yes, I know about cfront.

This is just another iteration on that old idea.

Post reply on HN