Who would have thought that OOP could be useful!
Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
41–50 of 131 posts
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#42Earlier quoted context omitted.
Much easier to link / load into other language binaries surely.
extern “C” works just fine.
Only in certain limited cases, for example, can't have static class instances or anything else that could require calling before a call from "extern C" API.
Also now you have to build enough of a C API to expose the features, extra annoying when you want the API to be fast so it better not involve extra level of indirections through marshalling (hello, KDE SMOKE)
At some point you're either dealing with limited non-C++ API, or you might find yourself doing a lot of the work twice.
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#43Earlier quoted context omitted.
You can take it a step further: - instead of setting the same function pointers on structs over and over again, point to a shared (singleton) struct named "vtable" which keeps track of all function pointers for this "type" of structs - create a factory function that allocates memory for the struct, initializes fields ("vtable" included), let's call it a "constructor" - make sure all function signatures in the shared…
Is this satire? That’s almost exactly the C++ way.
It's how you do it in many C++ implementations, but IIRC it's not actually mandated in any way unless you strive for GCC's IA-64 ABI compatibility (the effective standard on Linux for C++)
C++'s vtables are also, in my experience, especially bad compared to Objective-C or COM ones (MSVC btw generates vtables specifically aligned for use with COM, IIRC). Mind you it's been 15 years since I touched that part of crazy.
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#44This is an excellent pattern in C. The Dovecot mail server has many fine examples of the style as well e.g.
struct dict dict_driver_ldap = {
.name = "ldap",
.v = {
.init = ldap_dict_init,
.deinit = ldap_dict_deinit,
.wait = ldap_dict_wait,
.lookup = ldap_dict_lookup,
.lookup_async = ldap_dict_lookup_async,
.switch_ioloop = ldap_dict_switch_ioloop,
}
};
(those interested in a deeper dive might start at https://github.com/dovecot/core/blob/main/src/lib-dict/dict-...)
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#45Earlier quoted context omitted.
C is also C++, at least the C89 subset.
it actually isn't https://www.stroustrup.com/bs_faq.html#C-is-subset
Do you usually post links without reading them?
"In the strict mathematical sense, C isn't a subset of C++. There are programs that are valid C but not valid C++ and even a few ways of writing code that has a different meaning in C and C++. However, C++ supports every programming technique supported by C. Every C program can be written in essentially the same way in C++ with the same run-time and space efficiency. It is not uncommon to be able to convert tens of thousands of lines of ANSI C to C-style C++ in a few hours. Thus, C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985.
Well written C tends to be legal C++ also. For example, every example in Kernighan & Ritchie: "The C Programming Language (2nd Edition)" is also a C++ program. "
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#46Earlier quoted context omitted.
> weight and inconsistencies of (early) C++ Since very little is ever removed from C++, all the inconsistencies in C++ are still there.
Every language has inconsistencies, and C is not stranger to that. Much of c++’s baggage is due to C and you carry the same weight. That’s not to say that initialization isn’t broken in C++, but just like many features in many languages (off the top of my head in C - strcpy, sprintf, ctime are like hand grenades with the pin pre pulled for you) don’t use them. There’s a subset of C++17 that to me solves so many issue…
You could write this in C, no?
{ int val; if (getFoo(&val)) {
...
}}
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#47This is an excellent pattern in C. The Dovecot mail server has many fine examples of the style as well e.g. struct dict dict_driver_ldap = { .name = "ldap", .v = { .init = ldap_dict_init, .deinit = ldap_dict_deinit, .wait = ldap_dict_wait, .lookup = ldap_dict_lookup, .lookup_async = ldap_dict_lookup_async, .switch_ioloop = ldap_dict_switch_ioloop, } }; defines the virtual function table for the LDAP module, and any o…
So does the good old Quake 2 rendering API. The game exported a bunch of functions to the renderer via refimport_t and the renderer in return provided functions via refexport_t. The only visible symbol in a rendering DLL is GetRefAPI_t: https://github.com/id-Software/Quake-2/blob/master/client/re...
I remember being impressed by this approach, so I shamelessly copied it for my programming game: https://github.com/dividuum/infon/blob/master/renderer.h :)
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#48I'd say at 20kloc of C, https://www.lua.org/ gets you as far up the Object Oriented tower as you want.
The article is about using OO techniques directly in C code. Lua is implemented in C but it's an entirely separate language. Does its implementation use OO techniques as part of its C source code? If not, then it's not really relevant.
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#49Who would have thought that OOP could be useful!
This is not oop but polymorphism that is useful. And various forms of polymorphism are used in all kinds of programming paradigms.
Also, this is a nice way to get the damn banana without getting lost in the jungle.
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#50For the record, this design pattern is called a virtual method table, or vtable. I'm surprised that this article never mentioned the term. C++ programmers will know this pattern from the `virtual` keyword.
I've noticed many large C projects resort to these sorts of OOP-like patterns to manage the complexity of the design and size of the code base. But I'm not aware of any one standard way of doing this in C. It seems C++ standardized a lot of these concepts, or C++ developers adopted standard patterns somehow.