Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)

leandromoreira.com

Post reply on HN
Print view View original

11–20 of 131 posts

Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)

#11

Post by variadix »

MuffinFlavored wrote: post #10
social_quotient wrote: post #6

I spend a ton of time in FFmpeg, and I’m still blown away by how it uses abstractions to stay modular—especially for a project that’s been around forever and still feels so relevant. Those filtergraphs pulling off polymorphism-like tricks in C? It’s such an elegant way to manage complex pipelines. e.g. ffmpeg -i input.wav -filter_complex " [0:a]asplit=2[a1][a2]; [a1]lowpass=f=500[a1_low]; [a2]highpass=f=500[a2_high];…

how similar are the C abstractions in ffmpeg and qemu given they were started by the same person?

I haven’t worked with ffmpeg’s code, but I have worked with QEMU. QEMU has a lot of OOP (implemented in C obviously) that is supported by macros and GCC extensions. I definitely think it would have been better (and the code would be easier to work with) to use C++ rather than roll your own object model in C, but QEMU is quite old so it’s somewhat understandable. I say that as someone who mostly writes C and generally doesn’t like using C++.

Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)

#12

Post by sitkack »

jeroenhd wrote: post #5
mananaysiempre wrote: post #4

Earlier 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…

For those wishing Java had a similar feature, there's Manifold: https://github.com/manifold-systems/manifold/tree/master/man... Manifold is a very interesting project that adds a lot of useful features to Java (operator overloading, extension classes, and a whole bunch more). I don't know if it's smart to use it in production code because you basically go from writing Java to writing Manifold, but I still think it's…

http://manifold.systems/

> Manifold is a Java compiler plugin, its features include Metaprogramming, Properties, Extension Methods, Operator Overloading, Templates, a Preprocessor, and more.

Neat tool. It is like having a programmable compiler built into your language.

Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)

#14

Post by shmerl »

variadix wrote: post #11
MuffinFlavored wrote: post #10

Earlier quoted context omitted.

how similar are the C abstractions in ffmpeg and qemu given they were started by the same person?

I haven’t worked with ffmpeg’s code, but I have worked with QEMU. QEMU has a lot of OOP (implemented in C obviously) that is supported by macros and GCC extensions. I definitely think it would have been better (and the code would be easier to work with) to use C++ rather than roll your own object model in C, but QEMU is quite old so it’s somewhat understandable. I say that as someone who mostly writes C and generally…

What's the reason for ffmpeg to use C, also historic?

Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)

#15

Post by defrost »

shmerl wrote: post #14
variadix wrote: post #11

Earlier quoted context omitted.

I haven’t worked with ffmpeg’s code, but I have worked with QEMU. QEMU has a lot of OOP (implemented in C obviously) that is supported by macros and GCC extensions. I definitely think it would have been better (and the code would be easier to work with) to use C++ rather than roll your own object model in C, but QEMU is quite old so it’s somewhat understandable. I say that as someone who mostly writes C and generally…

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

Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)

#16

Post by JavierFlores09 »

mananaysiempre wrote: post #4
KerrAvon wrote: post #3

> The interface type in golang is much more powerful than Java’s similar construct because its definition is totally disconnected from the implementation and vice versa. We could even make each codec a ReadWriter and use it all around. This paragraph completely derailed me — I’m not familiar with golang, but `interface` in Java is like `@protocol` in Objective-C — it defines an interface without an implementation for…

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 funny thing about Java is that while its design is to be entirely nominally typed, the way it is implemented in the JVM is compatible with structural typing, but there are artificial limitations set to follow the intended design (though of course, if one were to disable these limitations then modeled type safety goes out of the window as Java was simply not designed to be used that way). One community which takes advantage of this fact is the Minecraft modding space, as it is the basis[1] of how modding platforms like Fabric work.

1: https://github.com/SpongePowered/Mixin/wiki/Introduction-to-...

Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)

#17

Post by emmelaich »

shmerl wrote: post #14
variadix wrote: post #11

Earlier quoted context omitted.

I haven’t worked with ffmpeg’s code, but I have worked with QEMU. QEMU has a lot of OOP (implemented in C obviously) that is supported by macros and GCC extensions. I definitely think it would have been better (and the code would be easier to work with) to use C++ rather than roll your own object model in C, but QEMU is quite old so it’s somewhat understandable. I say that as someone who mostly writes C and generally…

What's the reason for ffmpeg to use C, also historic?

Much easier to link / load into other language binaries surely.

Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)

#18

Post by owlstuffing »

mananaysiempre wrote: post #4
KerrAvon wrote: post #3

> The interface type in golang is much more powerful than Java’s similar construct because its definition is totally disconnected from the implementation and vice versa. We could even make each codec a ReadWriter and use it all around. This paragraph completely derailed me — I’m not familiar with golang, but `interface` in Java is like `@protocol` in Objective-C — it defines an interface without an implementation for…

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.

Re: Exploring Polymorphism in C: Lessons from Linux and FFmpeg's Code Design (2019)

#20

Post by billfruit »

mananaysiempre wrote: post #4
KerrAvon wrote: post #3

> The interface type in golang is much more powerful than Java’s similar construct because its definition is totally disconnected from the implementation and vice versa. We could even make each codec a ReadWriter and use it all around. This paragraph completely derailed me — I’m not familiar with golang, but `interface` in Java is like `@protocol` in Objective-C — it defines an interface without an implementation for…

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'?
Post reply on HN