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

Object-oriented design patterns in C and kernel development

oshub.org

Post reply on HN
Print view View original

171–180 of 224 posts

Re: Object-oriented design patterns in C and kernel development

#171

Post by 1718627440 »

TickleSteve wrote: post #151

Never. Do. This... I was involved in a product with a large codebase structured like this and it was a maintainability nightmare with no upsides. Multiple attempts were made to move away from this to no avail. Consider that the code has terrible readability due to no syntax-sugar, the compiler cannot see through the pointers to optimise anything, tooling has no clue what to do with it. On top of that, the syntax is o…

Can you elaborate what exactly the maintainability nightmare was?

To me less syntactic sugar is more readable, because you see what function call involves dynamic dispatch and which doesn't. Ideally it should also lead to dynamic dispatch being restricted to where it is needed.

I don't know where (might also have been LWN), but there was a post about it actually being more optimizable by the compiler, because dynamic code in C involves much less function pointers and the compiler can assume UB more often, because the assignments are in user code.

> requires any newbies to effectively understand how a c++ compiler

You are not supposed to reimplement a C++ compiler exactly, you are supposed to understand how OOP works and then this emerges naturally.

> dont try to turn C into a poor-mans C++

It's not poor-mans C++, when it's idiomatic C.

People like me very much choose C while having this usage in mind, because its clearer and I can sprinkle dynamism where it's needed not where the language/compiler prescribes it and because every dynamism is clear because there is not dynamic sugar, so you can't hide it.

Re: Object-oriented design patterns in C and kernel development

#172

Post by 1718627440 »

MangoToupe wrote: post #107

If this is the pattern you prefer, why not choose a language that caters to it? Choosing C just seems like you're TRYING to shoot yourself. I don't care how good you are at coding, this is just a bad decision.

Because they like how C caters to this. This question was asked here several times, please read the answers there.

Re: Object-oriented design patterns in C and kernel development

#173

Post by 1718627440 »

pjmlp wrote: post #146
mettamage wrote: post #66

Earlier quoted context omitted.

So why did Swift become a thing? Or does Swift has this too?

Because Objective-C being based on C, means it would never be safe while remaining compatible with C. Also dynamic runtime dispatch Smalltalk style can never be as fast as the VMT based dispatch, or compile time dispatch via generics, even with all the optimizations in place, that objc_msgSend() has had during its lifetime. Still, Metal is implemented in Objective-C, so there is that.

Objective-C already has a different compiler I fail to see how the compiler is restricted in the checks it does.

Re: Object-oriented design patterns in C and kernel development

#174

Post by 1718627440 »

wosined wrote: post #159

Hi, I don't know much about this. But it seems to me that the OP is doing it differently than the kernel devs. If you read the article that the OP links, then you get the impression that the vtables contain typed function pointers, while OP uses void pointers. Also the main benefit mentioned in the kernel dev article is that you save memory, by not having multiple function pointers in each structure instance, but ins…

> while OP use void pointers

OP doesn't use void pointers, he uses void. He writes about functions having no arguments and returning nothing for the same reason other blog posts name functions foo and bar.

> OP uses this vtable as a form of indirection to implement runtime method swapping and polymorphism

The kernel uses vtables to implement polymorphism, it doesn't store the vtable in the object to save space. If there is no polymorphism, you don't use a vtable at all, that's saving even more space.

Re: Object-oriented design patterns in C and kernel development

#175

Post by cryptonector »

guerrilla wrote: post #59
pakl wrote: post #34

A few years ago Peterpaul developed a lightweight object-oriented system on top of C that was really pleasant to use[0]. No need to pass in the object explicitly, etc. Doesn't have the greatest documentation, but has a full test suite (e.g., [1][2]). [0] https://github.com/peterpaul/co2 [1] https://github.com/peterpaul/co2/blob/master/carbon/test/pas... [2] https://github.com/peterpaul/co2/blob/master/carbon/test/pas…

For people wondering what it looks like without the syntactic sugar of carbon then look here [0]. As far as I can see, there's no support for parametric polymorphism. 0. https://github.com/peterpaul/co2/tree/master/examples/my-obj...

Objects yes, classes and inheritance no. Just interfaces please.

Re: Object-oriented design patterns in C and kernel development

#176

Post by ryao »

1718627440 wrote: post #165
ryao wrote: post #152

Earlier quoted context omitted.

You can take the API for a linked list and implement a balanced binary search tree behind it, but continuing to call it a linked list after doing that is wrong. Similarly, you can do pointer indirections the same way a vtable would do them, but if the things you get are not the equivalent of member function pointers, it is not a vtable.

> In computer programming, a virtual method table (VMT), virtual function table, virtual call table, dispatch table, vtable, or vftable is a mechanism used in a programming language to support dynamic dispatch (or run-time method binding). (Wikipedia) When its a table of function pointers used for dynamic dispatch, to me it's a vtable. I don't care about their type signatures as long as they logically belong to the o…

Read the definition again. The programming language here is not the one using this. It is the programmer using it.

Re: Object-oriented design patterns in C and kernel development

#177

Post by ryao »

1718627440 wrote: post #170
ryao wrote: post #153

Earlier quoted context omitted.

Static member functions are tied to the class while virtual member functions are tied to the object. If you throw the static member functions into a vtable, you will at best have a bug where the static member function from a different class can be called. Alternatively, you would have an undefined behavior where the other class in the hierarchy does not implement this function. There is a saying “If Your Only Tool Is…

> Static member functions are tied to the class while virtual member functions are tied to the object. That's nice, but the entire point is, that the caller doesn't know the type of the object, it only has a supertype. That's why you need dynamic dispatch here. Of course you can implement dynamic dispatch without function pointers, but it is done with function pointers here. If you don't want to name dynamic dispatch…

The vtable pointer corresponds to the actual type in languages that use vtables to implement inheritance, so you do know the type.

Read my previous comment for the bug that would happen if what us being used in Linux were actually used for dynamic dispatch when implementing inheritance, and it should be clear this is something similar, but different.

Re: Object-oriented design patterns in C and kernel development

#178

Post by ryao »

1718627440 wrote: post #169
ryao wrote: post #154

Earlier quoted context omitted.

The point of the vtable is to allow dynamic dispatch based on the actual type of an object. When you have a function that does not need a this pointer, it no longer depends on the type of the object and putting it in there anyway could cause you to execute a variant depending on the type of the object, which seems like a buggy undesirable behavior.

It can still depend on the type, the answer just doesn't need information from the instance. What speed limits can this road possibly have is a question I want to ask about this specific road. Yet this can be answered by referring to the country, which is already known when you create the road. But the user that asks this question can still ask this about roads in different countries, so this question still is valid.…

Let’s say I have ClassA::Foobar() and ClassB::Foobar(), and ClassB inherits from ClassA. Now let’s say I want to use ClassA::Foobar(), and I access it from the object because this pointer is in the vtable and the object is of type ClassB. Now ClassB::Foobar() executed, which is wrong. This is why static functions are not put into vtables. What Linux is doing is not a vtable, even if it shares similarities. Perhaps you would understand this if I said all thumbs are fingers, but not all fingers are thumbs.

Re: Object-oriented design patterns in C and kernel development

#179

Post by ryao »

mettamage wrote: post #66
pjmlp wrote: post #10

Earlier quoted context omitted.

Yes, that is how microservices were implemented in the days of NeXTSTEP. with PDO. https://en.wikipedia.org/wiki/Portable_Distributed_Objects

So why did Swift become a thing? Or does Swift has this too?

There is always a subset of the population for which it is fashionable to try to make a new language to make things easier. It is inevitable that someone in a sufficiently large organization will try to make one, provided management supports it. Apple is a very wealthy company that is happy to sponsor R&D, had someone interested in this that they sponsored and the result was appealing enough that they decided to adopt it.

That is my understanding of how the process generally works and what I am willing to guess happened. Prior to this, they had been making incremental changes to Objective-C.

That said, from what I have seen of the syntax of both languages, swift’s syntax is nicer and that is not something that they would have been able to get from Objective-C. They already had tried syntax reform for Objective-C once in the past and abandoned it.

Re: Object-oriented design patterns in C and kernel development

#180

Post by 1718627440 »

ryao wrote: post #176
1718627440 wrote: post #165

Earlier quoted context omitted.

> In computer programming, a virtual method table (VMT), virtual function table, virtual call table, dispatch table, vtable, or vftable is a mechanism used in a programming language to support dynamic dispatch (or run-time method binding). (Wikipedia) When its a table of function pointers used for dynamic dispatch, to me it's a vtable. I don't care about their type signatures as long as they logically belong to the o…

Read the definition again. The programming language here is not the one using this. It is the programmer using it.

Which means that it's not the language doing OOP, but the programmer.
Post reply on HN