Earlier quoted context omitted.
> Please, try not to be too dismissive to the things you do not understand. I never said it's impossible to do method polymorphism in C, I said nowhere in that article method polymorphism is implemented. You obviously did not read what I wrote at first place, only saw what you wanted to see to make some kind of (bad) rebuttal without a single concrete implementation as an example. Of course it's possible to implement…
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.
OOP in C
71–80 of 149 posts
Re: OOP in C
#72I 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.
Re: OOP in C
#73A 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)
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…
This book is a really fun read. You’ll learn a lot and get some interesting ideas.
Don’t listen to prescriptions from strangers on HN, how about? Myself included. :-)
Re: OOP in C
#74Beside the topic or the content, I love the typography choices of this.
Re: OOP in C
#75C 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’ve built it for now in a separate branch called “self”:
git clone -b self https://github.com/Sentido-Labs/cedro.git
cd cedro
make bin/cedro # Just “make” will build cedrocc etc.
bin/cedro - init();
list.init();
list->append(123);
list.append(123);
EOF
Result:
list->init(list);
list.init(&list);
list->append(list, 123);
list.append(&list, 123);
Re: OOP in C
#76Ok, but this is how pretty much all large programs were designed in assembler. C has the data structures commonly used in assembler. C++ (originally) removes some boilerplate and adds some comple-time checking.
Re: OOP in C
#77Ok, but this is how pretty much all large programs were designed in assembler . C has the data structures commonly used in assembler. C++ (originally) removes some boilerplate and adds some comple-time checking.
[deleted]
Re: OOP in C
#78Earlier quoted context omitted.
Using ADT to mean “abstract data type” does not mean anything more than what most people mean when they say “type”. Outside of distinguishing from other meanings of the word “type” there is no practical reason to ever say it. It doesn’t sound fancy, it just sounds like getting high on your own supply of acronyms. It is not an important term to learn as a beginner in the first chapters of a programming book. We should…
> Using ADT to mean “abstract data type” does not mean anything more than what most people mean when they say “type”. Abstract data type is a type where you don't get direct access to the information contained in it. The encapsulation is what makes it "abstract".
We should call it an opaque data type then.
Re: OOP in C
#79TLDR: 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 avoid the need for it in C?
I ask as a seasoned C++ and Java developer looking to improve some C code which uses this pattern in the extreme and needs some refactoring. My intuition is composition rather than inheritance, although isA is more intuitive than hasA for this code-base.
Re: OOP in C
#80Earlier quoted context omitted.
> Using ADT to mean “abstract data type” does not mean anything more than what most people mean when they say “type”. Abstract data type is a type where you don't get direct access to the information contained in it. The encapsulation is what makes it "abstract".
We should call it an opaque data type then.
That thing was named much before the other ADT became popular. The name is spread over a lot of past texts, and not in wide use anymore.
There's no point in changing anything.