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

101–110 of 131 posts

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

#101

Post by pjmlp »

p_l wrote: post #43
drivebyhooting wrote: post #30

Earlier quoted context omitted.

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.

It is more the other way around, COM was designed to fit with how MSVC generates vtables.

It is a simplification of OLE, and by the time the idea came up to use that approach, there were tons of OLE code since Windows 3.1.

By the way it wasn't gone away, after how Longhorn went down, it became the main API delivery mechanism on Windows, sadly improving the tooling has never been a pritority other than half-finished attempts.

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

#102

Post by pjmlp »

kazinator wrote: post #8
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…

GNU C++ once had this feature; it was called Signatures. It was removed, though. A signature declaration resembled an abstract base class. The target class did not have to inherit the signature: just have functions with matching names and types. The user of the class could cast a pointer to an instance of the class to a pointer to a compatible signature. Code not knowing anything about the class could indirectly call…

Nowadays you can do that with concepts.

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

#103

Post by pjmlp »

discreteevent wrote: post #73
chrsw wrote: post #50

Earlier quoted context omitted.

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.

> 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 The Power of Interoperability: Why Objects Are Inevitable https://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf

Objects regardless of what shape they take, are basically an evolution of modules that can be passed around as values, instead of having a single instance of them.

That is why they are here to stay, and even all mainstream FP and LP languages offer features that provide similar capabilities, even if they get other names for the same thing.

It is like saying an artifact is useless, only because it get named differently in English and Chinese.

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

#104

Post by josefx »

pjmlp wrote: post #67
josefx wrote: post #60

Earlier quoted context omitted.

> For example, every example in Kernighan & Ritchie: "The C Programming Language (2nd Edition)" is also a C++ program. " That is rather dated, they do things like explicitly cast the void* pointer returned by malloc, but point out in the appendix that ANSI C dropped the cast requirement for pointer conversions involving void , C++ does not allow implicit void conversions to this day.

> Well written C tends to be legal C++ also The "well written" remark is relevant. Many style guides will consider implicit void conversions not well written C. Naturally we are now on C23, and almost every C developer considers language extensions as being C, so whatever.

> The "well written" remark is relevant.

So using casts that hid implicit int declarations for years is "well written"?

> Many style guides will consider implicit void conversions not well written C.

I could not find a "Many" guide, Linux Kernel and ffmpeg seem to advocate against pointless casts.

> Naturally we are now on C23,

So irrelevant to the creation time of ffmpeg and only applicable to intentionally non portable libraries.

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

#105

Post by tialaramex »

uecker wrote: post #83
rowanG077 wrote: post #81

Earlier quoted context omitted.

C++ has a maybe type. It's called std::optional.

Here is my experimental maybe type for C: https://godbolt.org/z/YxnsY7Ted

Six divided by minus one is a "Division by zero" now? Where I come from that's minus six.

Good luck to WG14 (or maybe a faction within it?) as they seem to have decided to go make their own C++ competitor now, it's a weird time to do that, but everybody needs a hobby.

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

#106

Post by maccard »

uecker wrote: post #82
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…

This will be in C2Y and is already supported by GCC 15: https://godbolt.org/z/szb5bovxq

This is one example. Off the top of my head std.array vs "naked" C arrays, string vs const char*, and let's not forget RAII are all features that just make me never want to work with vanilla C ever again.

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

#107

Post by maccard »

i_am_a_peasant wrote: post #53
ablob wrote: post #46

Earlier quoted context omitted.

You could write this in C, no? { int val; if (getFoo(&val)) { ... }} Both ways of expressing this are weird, but stating that this can't be achieved with C is dishonest in my opinion.

it's not that weird to explicitly limit the scope of certain variables that logically belong together. But i agree the C++ if(init;cond) thing was new to me.

Like everything in C++, it has it's share of footguns

    if (Foo* f = GetPtr(); f->HasValue()) {} // wrong; f can be null
vs

    if (Foo* f = GetPtr(); f && f->HasValue()){}
Is probably the biggest pitfall. Especially if you're used to this:

    if (Foo* f = GetPtr())
    {
        f->DoTheThing(); // this is perfectly safe.
    }

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

#108

Post by jcelerier »

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.

> But then again Rust devs are more likely to use static dispatch via generics if performance is critical.

I'm not sure I follow - pretty much 99% of usage of C++ in the last, like, 20 years has been around making sure that you get static dispatch with polymorphism through templates. It's exceedingly uncommon to see the `virtual` keyword unless you have, say, some DLL-based run-time plug-in system going on.

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

#109

Post by DarkUranium »

favorited wrote: post #95

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

The same is visible in having to parse a bunch of Linux's more complex of the /proc entries, vs. simply using syscalls in (say) FreeBSD.

"Everything is a file" is not a bad abstraction for some things. It feels like Linux went the route of a golden hammer here.

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

#110

Post by procaryote »

pjmlp wrote: post #45
procaryote wrote: post #38

Earlier quoted context omitted.

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…

I don't see your point. The thing you quote explicitly says C isn't a subset of C++.

> Well written C tends to be legal C++ also

and python2 can be written to be compatible with python3, but neither is a subset of the other

Post reply on HN