31–40 of 149 posts
[flagged]
Charitability is not a tool merely for being nice to others, but being nice to yourself. You learn more this way.
Earlier quoted context omitted.
Polymorphism in C is trivial: You use a vtable - a struct of method pointers. Same approach most languages with "simple" method resolution mechanisms, like e.g C++, uses under the hood. You don't need macros. You either call via the vtable, or you write a wrapper per interface per message. E.g. struct class { void (*vtable[NUM_SLOTS]); }; struct object { struct class * class; }; typedef struct object object; const in…
what does an "object" look like? how do i derive from it?
Simple example here: https://embeddedgurus.com/state-space/2008/01/object-based-p...
Lots more here: https://stackoverflow.com/questions/351733/how-would-one-wri...
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.
Earlier quoted context omitted.
Nothing in your example looks or reads as trivial . That is a gross perversion of a simple procedural language.
Trivial to a C developer then. This has been typical of C code for literally decades. The only thing that sucks there is writing wrappers, but it's easy to generate them. From a user point of view you end up doing things like: string * str = string_new(); int len = string_length(str); So it looks just like most other typical C code using prefixes per interface and passing pointers to structs around. In practice, like…
Oh.My.God.
At this point, you might as well be using Java.
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.
That wouldn't actually help much. In the case that there is no inheritance, using a function pointer has unnecessary overhead (pointer storage, indirect call, additional parameter). In the case of inheritance, the pointer type differs and thus the function pointer type wouldn't be compatible either.
Earlier quoted context omitted.
Trivial to a C developer then. This has been typical of C code for literally decades. The only thing that sucks there is writing wrappers, but it's easy to generate them. From a user point of view you end up doing things like: string * str = string_new(); int len = string_length(str); So it looks just like most other typical C code using prefixes per interface and passing pointers to structs around. In practice, like…
"int string_length(void * self) { return ((int ( )(void ))((object *)self)->class->vtable[STRING_LENGTH_SLOT])(self);" Oh.My.God. At this point, you might as well be using Java.
If you want simpler models see my other comments in this thread.
Earlier quoted context omitted.
Trivial to a C developer then. This has been typical of C code for literally decades. The only thing that sucks there is writing wrappers, but it's easy to generate them. From a user point of view you end up doing things like: string * str = string_new(); int len = string_length(str); So it looks just like most other typical C code using prefixes per interface and passing pointers to structs around. In practice, like…
"int string_length(void * self) { return ((int ( )(void ))((object *)self)->class->vtable[STRING_LENGTH_SLOT])(self);" Oh.My.God. At this point, you might as well be using Java.
But of course if you're going to reimplement OO from scratch in C you will see the entire machinery laid bare. You're only doing it in the first place either because you're committed to using C for whatever reason, or to understand OO implementation strategies.
Preferably using int/float which should be atomic on X86 and hopefully on modern ARM too, don't know about RISC-V yet.
[flagged]
>Classes in an object oriented design are fundamentally ADTs
It isn't. I would suggest the paper Object-Oriented Programming Versus Abstract Data Types by William R. Cook which explains the fundamental differences between the two data abstraction techniques.
edit:
https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOO...
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.
That wouldn't actually help much. In the case that there is no inheritance, using a function pointer has unnecessary overhead (pointer storage, indirect call, additional parameter). In the case of inheritance, the pointer type differs and thus the function pointer type wouldn't be compatible either.
> 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.