If you need to do OOP in C, it's time to move to a more powerful language.
You could always use a lang that is a Superset of C if you so badly want it for OOP purposes
Object-Oriented Programming in C (2019) [pdf]
61–70 of 95 posts
Re: Object-Oriented Programming in C (2019) [pdf]
#62Earlier quoted context omitted.
saying OOP is only useless and counter productive is as short sighted as saying it is the golden hammer for everything. PS: WinUI apps use plenty OOP
It's not what i've said, OOP is great for creating APIs like WinUI, not great for writing applications
In which universe an application which uses mainly OOP APIs isn't itself OO.
Re: Object-Oriented Programming in C (2019) [pdf]
#63Earlier quoted context omitted.
Not an array, a struct is ok, and in C99 style it is very well readable. For example Linux Kernel style is: static const struct file_operations fops = { .open = my_open, .release = my_release, .read = my_read, .write = my_write }; that's all, very straightforward. Also there is no need to prefix the function name with &
This pattern goes back to pre-Version-7 UNIX kernels, with only minor syntactic updates. That it long predates OO demonstrates it is not OO. That does not make it any less effective, or less useful.
> That it long predates OO demonstrates it is not OO.
This does not make any sense. People did not wait until someone gave a name to the rule-of-three to use it, and that does not make these uses any less rule-of-three than the ones that occured post-naming.
Re: Object-Oriented Programming in C (2019) [pdf]
#64OOP in C inevitably leads to LOTS of pointer dereferencing. Pointer dereferencing hurts performance.
OOP in C++ leads to twice as much pointer dereferencing. Just that you don't see it doesn't mean it does not exist. Look at the generated code. It sucks. The best thing in C++ is compile-time computation (ignoring the horrible template syntax). OO is not esp. well implemented.
Inlining the ctable into the object would only be faster if
- you have very few objects
- you have very few virtual functions
If you have a lot of objects or a lot of virtual functions, things will be less likely to fit in cache which will entirely destroy your performance, by an order of magnitude when compared to a mostly-always-branch-predicted indirection.
I remember experimenting with a an "inlined" version of std:: function and just having inlined the 5 ctor/move ctor/copy ctor/assignment operators was already slower than the vtable version when going through hundreds of callbacks ; imagine for something like Qt where QWidget or QGraphicsItem have 20+ virtual methods.
Re: Object-Oriented Programming in C (2019) [pdf]
#65If you need to do OOP in C, it's time to move to a more powerful language.
Really? Linux kernel uses extensive OOP/C.
Re: Object-Oriented Programming in C (2019) [pdf]
#66The best OOP with C comes from a book called "Extreme C", if you're interested, check it out.
Re: Object-Oriented Programming in C (2019) [pdf]
#67I think this approach is working too hard to realize Virtual Tables and Virtual Pointers. Another, different implementation is to define an array of function pointers, one function per method implemented, and then extend the array per subclass; each child class fills in its own or parents function pointers at init time.
Not an array, a struct is ok, and in C99 style it is very well readable. For example Linux Kernel style is: static const struct file_operations fops = { .open = my_open, .release = my_release, .read = my_read, .write = my_write }; that's all, very straightforward. Also there is no need to prefix the function name with &
PP (parent post) here - yes, several variations available in C99; I haven't tried to retrieve my examples yet. (I used this commercially in the 90s)
Re: Object-Oriented Programming in C (2019) [pdf]
#68Earlier quoted context omitted.
It's a measurable difference. OO in C++ must use double indirect vtable method calls, whilst this OO in C uses only one indirection. It's measurably faster. Objects are a bit larger though, cloning is a bit more expensive, but method calls are much faster and much easier to cache.
I think you're misinterpreting GP's code. It is a vtable, hence the static const . There would be a pointer in each struct "instance" to this static vtable, thus the same double indirection would occcur as in C++.
OP mimic'd C++ vtables. But in C you can do better and inline them. I mostly inline them for performance reasons.
Re: Object-Oriented Programming in C (2019) [pdf]
#69Earlier quoted context omitted.
It's not what i've said, OOP is great for creating APIs like WinUI, not great for writing applications
In which universe an application which uses mainly OOP APIs isn't itself OO.
What OOP is good at is maintenance over the time by making clear what is API and what is implementation.
My point is that when you develop an application, you only need strawman OOP i.e. calling methods.
You don't need class inheritance if you can pass functions as parameters, you don't need encapsulation given all your pieces co-evolve at the same time (if it's not split than part into a library).
Re: Object-Oriented Programming in C (2019) [pdf]
#70I think this approach is working too hard to realize Virtual Tables and Virtual Pointers. Another, different implementation is to define an array of function pointers, one function per method implemented, and then extend the array per subclass; each child class fills in its own or parents function pointers at init time.
What would also be helpful is a standard way to declare to the compiler that it should or should not optimize each flagged polymorphic late bound call implementation to be early bound; moving the calls into separate or merged files during linking is not an in context solution.
not really important, retrieval of a function pointer at a known slot, and then calling that function pointer, can be really fast on a lot of arch.