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

121–130 of 149 posts

Re: OOP in C

#121

Post by anthomtb »

oso2k wrote: post #116
posharma wrote: post #110

While I commend this effort I should say that seriously, just write C++ if possible. No matter what you do memory management is going to be your biggest enemy (I’m ignoring the aesthetic aspects like macros, function pointers, type safety, etc). Without RAII it’s just not worth it. Just choose the simpler portions of C++ and keep safe.

You can do RAII in C. You still have to define a dtor function. https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...

Is "dtor" shorthand for destructor?

Re: OOP in C

#122

Post by jacquesm »

anthomtb wrote: post #121
oso2k wrote: post #116

Earlier quoted context omitted.

You can do RAII in C. You still have to define a dtor function. https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...

Is "dtor" shorthand for destructor?

Yes, just like ctor is constructor.

Re: OOP in C

#123

Post by oso2k »

anthomtb wrote: post #121
oso2k wrote: post #116

Earlier quoted context omitted.

You can do RAII in C. You still have to define a dtor function. https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...

Is "dtor" shorthand for destructor?

Yes! You got it.

Re: OOP in C

#124

Post by KerrAvon »

AlbertoGP wrote: post #100
Koshkin wrote: post #95

Earlier quoted context omitted.

> 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.

Sure; you’re basically implementing The prehistoric version of C++, called “C with Classes.” If you’re unaware, see Stroustrup’s Design and Evolution of C++ book.

Which is fine! Should be interesting.

Re: OOP in C

#125

Post by orlp »

quelsolaar wrote: post #107
attractivechaos wrote: post #69

Earlier quoted context omitted.

The webpage in the title is pretty good. It explains most things you need to achieve OOP in C. This PDF however pushes C for what it is not intended for, which leads to inefficient and obscure code. For example, the first example in the PDF implements a Set. Everything is "void". This loses typing and will make code hard to read and maintain. The way inheritance is mimicked is hideous and inefficient. The PDF also he…

I have not read the book. > However, C is not C++ and is not intended for providing all OOP features like inheritance. There are parts of the ISO C standard specifically included to allow for inheritance. Consider: typedef struct{ int x; }struct_a; typedef struct{ struct_a inherited; int y; }struct_b; void function(struct_a *s) { s->x = 0; } Here struct_b inharates struct_a. You can call the function with either a po…

Doesn't this violate strict aliasing? E.g. what if we do this?

    void foo(struct_a *a, struct_b *b) { a->x = 0; b->x += 1; a->x = 0; }
Strict aliasing allows the compiler to elide the second a->x = 0. But if we use your inheritance scheme using casting of pointers, we could have a == b.

Re: OOP in C

#126

Post by yakkityyak »

posharma wrote: post #110

While I commend this effort I should say that seriously, just write C++ if possible. No matter what you do memory management is going to be your biggest enemy (I’m ignoring the aesthetic aspects like macros, function pointers, type safety, etc). Without RAII it’s just not worth it. Just choose the simpler portions of C++ and keep safe.

Yeah, I feel like “C in a C++ Compiler” is a respectable decision for reasons similar to what you describe.

Re: OOP in C

#127

Post by isityouyesitsme »

lll-o-lll wrote: post #118
isityouyesitsme wrote: post #108

Earlier quoted context omitted.

Your straw men fall easily. But your "snipe" doesn't even apply. I spent the two years of my masters program editing a NASA-owned LISP codebase. it wasn't huge. Maybe 100kloc. But I'm definitely not ignorant or LISP. Look, you don't like OOP, who cares? I certainly don't. But that's different than trying to explain that you have a fundamental misunderstanding. Whether you accept it or not, it's in your head now ;)

I’m too old and tired for the insult slinging anyway. What’s my fundamental misunderstanding? What’s the straw man? Class == re-use? I don’t hate OO by the way, it’s just not the first, only, or in my opinion best way to think about or structure code. I do think the expectations that OO would bring increased productivity, code-reuse, etc were not realised and hence why I referred to it as a “failed paradigm”. Not bec…

I can agree with a lot of what you wrote, and especially outcome vs. the original OOP promises. They meant one thing, and it turned out that thing is actually an anti pattern (inheriting implementations and state, not merely inheriting interfaces), but then they also delivered on what they said, just in a different way. Example: "we will have reusable code!" What they meant was deep inheritance hierarchies where children just inherit their parent code and selectively override parts of it. What was delivered instead was a set of principles using the vocabulary of OOP to guide developers into designing interfaces that are highly reusable (SOLID).

In terms of what this adds to C, I can only suggest that you study a large C project. I'd recommend the Linux kernel. You won't find first-class support for inheritance and polymorphism, but it's there. It is amazing how modifiable and extensible entire subsystems are, and when you examine it, you find the SOLID principles at work, which came from OOP study and practice.

I don't really understand what you mean by the way OOP is "structured." If you're referring to deep object hierarchies like Java or Qt, I don't really disagree. They attempt to force an architectural unity through object hierarchies. But then on the other hand, if you're saying that it isn't helpful to contemplate an architecture through the lense of types, the types of transformations and operations that can be performed on them, and packaging these operators and transformers into a group that can be passed to code that calls them abstractly, then I don't agree.

Amusingly, I don't think that second thing is what you're saying. But with your arguing against OOP, I don't really know how to interpret this. This is what OOP gave us language to describe. Of course some of these techniques existed before in LISP or C, but code bases of the day were largely NOT leveraging them in any large scale way. OOP gave us vocabulary for these concepts, as well as mainstreamed their use, similar to how functional programming mainstreamed the idea that a nonlinear or cyclic graph of executable functions must not allow shared state, even if hidden within objects, if you want to be able to maintain that code long term, and extend it. So it seems like you're arguing that OOP is bad, while neglecting the history that OOP brought us the common understanding of how modules should interact with each other.

Re: OOP in C

#128

Post by andrekandre »

alerighi wrote: post #68
Aisen8010 wrote: post #65

Earlier quoted context omitted.

Inheritance is the best solution to some problems. It got a bad reputation because it was abused. Bad practice is using inheritance when a tuple or a map would suffice.

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…

  > has a ton of problems
this may be a good reference with examples (and some good dose of nuance) on the subject:

https://blog.gougousis.net/oop-inheritance-what-when-and-why...

Re: OOP in C

#129

Post by augustk »

JonChesterfield wrote: post #83
augustk wrote: post #72

Earlier quoted context omitted.

An abstract data type (ADT) is a structured type for which a client cannot access the data components for variables of this type. The client understands the type in terms of its operations, provided by a set of functions which operates on variables of this type. The set of functions is called the interface of the ADT. Note that this definition requires information hiding but not inheritance or polymorphism.

How would you distinguish that definition from one for "type"?

> How would you distinguish that definition from one for "type"?

The crucial difference between an abstract data type and a concrete data type is that the content is hidden in the former case.

Re: OOP in C

#130

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]
Post reply on HN