*int (*encode)(*int); Why not compile your snippets? Heads up to the author.
[dead]
Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
21–30 of 131 posts
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#22Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#23Earlier quoted context omitted.
The difference between Go and Java is that in Go a type need not declare its adherence to an interface up front—any type that has methods of appropriate names and signatures is considered to implement the interface, even if its designers were not aware of the interface’s existence. (This involves a small bit of dynamism in the runtime; easily cached, though, as the set of methods of a given type and the set of all in…
So golang supports 'duck typing'?
I think in a static context, it's generally referred to as structural typing, but yeah.
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#24Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#25Earlier quoted context omitted.
The difference between Go and Java is that in Go a type need not declare its adherence to an interface up front—any type that has methods of appropriate names and signatures is considered to implement the interface, even if its designers were not aware of the interface’s existence. (This involves a small bit of dynamism in the runtime; easily cached, though, as the set of methods of a given type and the set of all in…
>The difference between Go and Java is that in Go a type need not declare its adherence to an interface up front. Go can't declare adherence up front, and in my view that’s a problem. Most of the time, explicitly stating your intent is best, for both humans reading the code and tools analyzing it. That said, structural typing has its moments, like when you need type-safe bridging without extra boilerplate.
You can assert that your type implements an interface at compile time, though, e.g.
var _ AssertedInterface = &MyType{}Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#26Earlier quoted context omitted.
What's the reason for ffmpeg to use C, also historic?
Fabrice also wrote the Tiny C compiler, so very much his language of choice .. For those used to the language it was seen as "lighter" and easier to add OO like abstractions to your C usage than bog down in the weight and inconsistencies of (early) C++ https://bellard.org/ https://en.wikipedia.org/wiki/Fabrice_Bellard
> weight and inconsistencies of (early) C++
Since very little is ever removed from C++, all the inconsistencies in C++ are still there.
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#27For 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.
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 struct start with a pointer to the original struct as the first parameter, a good name for this argument would be "this"
- encode parameter types in the function name to support overloading, e.g. "func1_int_int"
- call functions in the form of "obj->vtable->func1_int_int(obj, param1, param2)"
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#28The language is called Go.
Other than that, yeah doing by hand what C++ and Objective-C do automatically.
Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#29Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)
#30For 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.
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.