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

81–90 of 149 posts

Re: OOP in C

#81

Post by asveikau »

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…

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.

Re: OOP in C

#82

Post by JonChesterfield »

ryanianian wrote: post #79

TLDR: Put data members in a struct. Write a function per "method" and pass in the `this` pointer. Simple and effective. BUT: inheritance. C++ has subclasses (`class Manager : Employee`) and virtuals / vtable lookup on pointer access (`employee->name()` which calls `Manager::name` or `Employee::name` based on type). What is the typical equivalent in C? Hand-rolled vtables? Or is there a general paradigm that helps to…

You're going to think this is a joke but I'm mostly sincere The right refactor is to untangle the data structures, write a lua interface to them, then port the application logic to lua. Since (one of the) lua is written in C your codebase is still all C.

Re: OOP in C

#83

Post by JonChesterfield »

augustk wrote: post #72
redgrange wrote: post #50

I see so many uses of the term ADT that I can't really give anyone a confident definition

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"?

Re: OOP in C

#84

Post by tpoacher »

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 wasn't too keen on this book. I read it hoping it would be more like the article in this post. But I felt it was more a case of someone re-inventing c++ with macros.

Re: OOP in C

#85

Post by _0w8t »

Aisen8010 wrote: post #65
alerighi wrote: post #40

Earlier quoted context omitted.

Inheritance is nowadays almost considered a bad practice, in fact newer languages, such as Rust, doesn't support it, and in languages that has it (Java, C#, etc) nowadays they always tell you to prefer composition over inheritance. > using a function pointer has unnecessary overhead This is true, it's inefficient. But for a lot of application, also irrelevant at performance level, and would provide a good abstraction…

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.

The main issue with inheritance is hard coupling of data and code. As code evolve from data modeling point of view it can be advantages to split the state managed by one object into several data structures. With data inheritance such refactoring is almost impossible. When inheritance is limited only to pure interfaces the access to the state is not hard-coded and can be redirected as necessary.

Re: OOP in C

#86

Post by [deleted] »

JonChesterfield wrote: post #82
ryanianian wrote: post #79

TLDR: Put data members in a struct. Write a function per "method" and pass in the `this` pointer. Simple and effective. BUT: inheritance. C++ has subclasses (`class Manager : Employee`) and virtuals / vtable lookup on pointer access (`employee->name()` which calls `Manager::name` or `Employee::name` based on type). What is the typical equivalent in C? Hand-rolled vtables? Or is there a general paradigm that helps to…

You're going to think this is a joke but I'm mostly sincere The right refactor is to untangle the data structures, write a lua interface to them, then port the application logic to lua. Since (one of the) lua is written in C your codebase is still all C.

[deleted]

Re: OOP in C

#87

Post by _0w8t »

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.

Re: OOP in C

#88

Post by carapace »

Or you could implement COLA?

https://en.wikipedia.org/wiki/COLA_(software_architecture)

Huh, that page was deleted in Dec 22. "concern was: Old research project. Unable to locate any details. VPRI institute is dead. Been on the cat:nn list since March 2009. No new updates."

Goddamned deletionist activist WP editors tearing down the human knowledge base.

(If you don't know VPRI is (was?) Alan Kay's research org. I think it's a bit notable and important.)

ANYWAY

From the search result (in DDG) snippet I can get the first two sentences of the deleted page:

> "COLA" stands for "Combined Object Lambda Architecture". [1] A COLA is a self-describing language in two parts, an object system which is implemented in terms of objects, and a functional language to describe the computation to perform. [2]

It's a very simple system that gives you the basis for both OOP and Lisp-like semantics. It's fun!

You can see it here: https://piumarta.com/software/cola/

Or check out the VPRI reports, etc.:

https://web.archive.org/web/20220819075633/https://www.vpri....

Ironically their website appears to be down at the moment.

Re: OOP in C

#89

Post by flohofwoe »

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

Re: OOP in C

#90

Post by lll-o-lll »

isityouyesitsme wrote: post #43
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.

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.

Post reply on HN