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

91–100 of 131 posts

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

#91

Post by pjmlp »

programmarchy wrote: post #89
pjmlp wrote: post #28

The language is called Go. Other than that, yeah doing by hand what C++ and Objective-C do automatically.

For one, ffmpeg is 9 years older than Go. Plus, when dealing with video files a garbage collected language probably isn't going to cut it. C++ and Obj-C also feel overkill for ffmpeg.

Apparently someone has not read the article, otherwise you would have had understood my point about Go.

Secondly, Apple and Microsoft, do just fine with Objective-C and C++ for their video codecs, without having to manually implement OOP in C.

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

#92

Post by maccard »

tialaramex wrote: post #76
maccard wrote: post #35

Earlier quoted context omitted.

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…

Variables like "valueSet" scream out that the language lacks a Maybe type instead. One of the worst things about C++ is that it's content to basically not bother improving on the C type system.

C++ has optional, but I wanted to demonstrate that you could wrap a C API in a safer more ergonomic way.

If you rewrote it in a more modern way and changed the API

    std::optional getFoo();

    if (auto val = getFoo()) {}
There are lots of improvements over C’s type system - std.array, span, view, hell even a _string_ class

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

#93

Post by maccard »

trelane wrote: post #86
ho_schi wrote: post #62

Earlier quoted context omitted.

For C users. And C++ users: In C++ we can declare variable in the while or if statement: https://en.cppreference.com/w/cpp/language/while https://en.cppreference.com/w/cpp/language/if It's value is the value of the decision. This is not possible with C [1]. Since C++17 the if condition can contain an initializer: Ctrl+F if statements with initializer https://en.cppreference.com/w/cpp/language/if Which sounds like the…

Declaring a variable in a loop or if statement is supported since C99: https://en.wikipedia.org/wiki/C99 Also in Java: https://www.geeksforgeeks.org/for-loop-java-important-points...

No, declaring a variable in a `for` loop is supported in C99 but you can't do if-init.

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

#94

Post by pornel »

i_am_a_peasant wrote: post #55
jcelerier wrote: post #51

Earlier quoted context omitted.

and C++ also supports optimizing them, especially when you use `final` keyword and LTO which is able to devirtualize at the scale of a whole program.

Interesting, in Rust those optimizations are more implicit since there's no "final" keyword when you use dynamic dispatch via trait objects. + you also got LTO. I wonder if there are many cases where C++ will devirtualize and Rust won't. But then again Rust devs are more likely to use static dispatch via generics if performance is critical.

In Rust objects can dynamically go in and out of having virtual dispatch. The vtable is only in the pointer to the object, so you can add or remove it. Take a non-virtual object, lend it temporarily as a dynamically dispatched object, and then go back to using it directly as a concrete type, without reallocating anything.

That's pretty powerful:

• any type can be used in dynamic contexts, e.g. implement Debug print for an int or a Point, without paying cost of a vtable for each instance.

• you don't rely on, and don't fight, devirtualization. You can decide to selectively use dynamic dispatch in some places to reduce code size, without committing to it everywhere.

• you can write your own trait with your own virtual methods for a foreign type, and the type doesn't have to opt-in to this.

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

#95

Post by favorited »

> for instance, Linux handles network socket, special files (like /proc/cpuinfo) or even USB devices as files. This is a powerful idea that can make easy to write or use programs for linux since we can rely in a set of well known operations from this abstraction called file.

Benno Rice gave a fantastic talk a few years ago called "What UNIX Cost Us," which he starts off by showing how to write some USB device code in macOS, Windows, and Linux. It only takes a few minutes to demonstrate how pretending that everything is a file can be a pretty poor abstraction, and result in far more confusing code, which is why everyone ends up using libusb instead of sysfs.

https://www.youtube.com/watch?v=9-IWMbJXoLM#t=134s

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

#96

Post by jamesfinlayson »

dividuum wrote: post #47
inopinatus wrote: post #44

This 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/div…

Pretty sure Half-Life does something pretty similar - all functionality between the game and engine is done via function pointer structs.

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

#97

Post by trelane »

maccard wrote: post #93
trelane wrote: post #86

Earlier quoted context omitted.

Declaring a variable in a loop or if statement is supported since C99: https://en.wikipedia.org/wiki/C99 Also in Java: https://www.geeksforgeeks.org/for-loop-java-important-points...

No, declaring a variable in a `for` loop is supported in C99 but you can't do if-init.

Ah, you're right (finally tried it out). But it 100% works in a loop (usually for loop)

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

#98

Post by flykespice »

vkazanov wrote: post #49
high_na_euv wrote: post #41

Who 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.

isnt polymorphism inherently a subset of oop?

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

#99

Post by vkazanov »

flykespice wrote: post #98
vkazanov wrote: post #49

Earlier quoted context omitted.

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.

isnt polymorphism inherently a subset of oop?

No, all popular functional languages have one flavour of polymorphism or the other.

Or, in math speak, Oop means polymorphism but polymorphism doesn't mean oop.

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

#100

Post by pjmlp »

tialaramex wrote: post #76
maccard wrote: post #35

Earlier quoted context omitted.

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…

Variables like "valueSet" scream out that the language lacks a Maybe type instead. One of the worst things about C++ is that it's content to basically not bother improving on the C type system.

I would vouch that C++ has plenty of improvements of C type system, even C++ARM already provided enough improvements that I never liked plain old C, other than that year spent learning C via Turbo C 2.0, before being given access to Turbo C++ 1.0 for MS-DOS in 1993.

The problem is all the folks that insist coding in C++ as if it was C, ignored all those C++ improvements over C.

Post reply on HN