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

11–20 of 224 posts

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

#11

Post by ryao »

trws wrote: post #3
ryao wrote: post #2

> The article describes how the Linux kernel, despite being written in C, embraces object-oriented principles by using function pointers in structures to achieve polymorphism. This technique predates object oriented programming. It is called an abstract data type or data abstraction. A key difference between data abstraction and object oriented programming is that you can leave functions unimplemented in your abstrac…

I largely agree, and use these patterns in C, but you’re neglecting the usual approach of having a default or stub implementation in the base for classic OOP. There’s also the option of using interfaces in more modern OOP or concept-style languages where you can cast to an interface type to only require the subset of the API you actually need to call. Go is a good example of this, in fact doing the lookup at runtime…

My point is that this pattern is not object oriented programming. As for a default behavior with it, you usually would do that by either always adding the default pointer when creating the structure or calling the default whenever the pointer is NULL.

In the Linux VFS for example, there are optimized functions for reading and writing, but if those are not implemented, a fallback to unoptimized functions is done at the call sites. Both sets are function pointers and you only need to implement one if I recall correctly.

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

#12

Post by 1718627440 »

ryao wrote: post #2

> The article describes how the Linux kernel, despite being written in C, embraces object-oriented principles by using function pointers in structures to achieve polymorphism. This technique predates object oriented programming. It is called an abstract data type or data abstraction. A key difference between data abstraction and object oriented programming is that you can leave functions unimplemented in your abstrac…

> This technique predates object oriented programming.

I would rather say that OOP is a formalization of predating patterns and paradigma.

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

#13

Post by pjmlp »

ryao wrote: post #9
mistrial9 wrote: post #5

Earlier quoted context omitted.

The concept of abstract data type is a real idea in the days of compiler design. You might as well say "compiler design predates object oriented programming". The technique described in the lead is used to implement object-oriented programming structures, just as it says. So are lots of compiler design features under the hood. source- I wrote a windowing framework for MacOS using this pattern and others, in C with Me…

Compiler design does predate object oriented programming. The first compiler was made by John Backus et al at IBM in April 1957. As for abstract data types, they originated in Lisp, which also predates object oriented programming.

Actually, no.

"AN ALGORITHMIC THEORY OF LANGUAGE", 1962

https://apps.dtic.mil/sti/tr/pdf/AD0296998.pdf

In this paper they are known as plexes, eventually ML and CLU will show similar approaches as well.

Only much latter would Lisps evolve from plain lists and cons cells.

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

#14

Post by spacechild1 »

1718627440 wrote: post #4

> Having to pass the object explicitly every time feels clunky, especially compared to C++ where this is implicit. I personally don't like implicit this. You are very much passing a this instance around, as opposed to a class method. Also explicit this eliminates the problem, that you don't know if the variable is an instance variable or a global/from somewhere else.

> Also explicit this eliminates the problem, that you don't know if the variable is an instance variable or a global/from somewhere else.

People typically use some kind of naming convention for their member variables, e.g. mFoo, m_Foo, m_foo, foo_, etc., so that's not an issue. I find `foo_` much more concise than `this->foo`. Also note that you can use explicity this in C++ if you really want to.

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

#15

Post by elteto »

1718627440 wrote: post #4

> Having to pass the object explicitly every time feels clunky, especially compared to C++ where this is implicit. I personally don't like implicit this. You are very much passing a this instance around, as opposed to a class method. Also explicit this eliminates the problem, that you don't know if the variable is an instance variable or a global/from somewhere else.

...and C++ added explicit this parameters (deducing this) in C++23.

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

#16

Post by loeg »

1718627440 wrote: post #4

> Having to pass the object explicitly every time feels clunky, especially compared to C++ where this is implicit. I personally don't like implicit this. You are very much passing a this instance around, as opposed to a class method. Also explicit this eliminates the problem, that you don't know if the variable is an instance variable or a global/from somewhere else.

I think the author is talking about this:

  object->ops->start(object)
Where not only is it explicit, but you need to specify the object twice (once to resolve the Vtable, and a second time to pass the object to the stateless C method implementation).

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

#17

Post by tdrnl »

A talk[0] about Tmux is where I learned about this pattern in C.

I wrote about this concept[1] for my own understanding as well -- just tracing the an instance of the pattern through the tmux code.

[0] https://raw.githubusercontent.com/tmux/tmux/1536b7e206e51488... [1] https://blog.drnll.com/tmux-obj-oriented-commands

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

#18

Post by f1shy »

ryao wrote: post #11
trws wrote: post #3

Earlier quoted context omitted.

I largely agree, and use these patterns in C, but you’re neglecting the usual approach of having a default or stub implementation in the base for classic OOP. There’s also the option of using interfaces in more modern OOP or concept-style languages where you can cast to an interface type to only require the subset of the API you actually need to call. Go is a good example of this, in fact doing the lookup at runtime…

My point is that this pattern is not object oriented programming. As for a default behavior with it, you usually would do that by either always adding the default pointer when creating the structure or calling the default whenever the pointer is NULL. In the Linux VFS for example, there are optimized functions for reading and writing, but if those are not implemented, a fallback to unoptimized functions is done at th…

To be fair, OOP is not 100% absolutely perfectly defined. Strustrup swears C++ is OOP, Alan Key, at least at some point laughed at C++, and people using CLOS have yet another definition

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

#20

Post by naasking »

ryao wrote: post #11
trws wrote: post #3

Earlier quoted context omitted.

I largely agree, and use these patterns in C, but you’re neglecting the usual approach of having a default or stub implementation in the base for classic OOP. There’s also the option of using interfaces in more modern OOP or concept-style languages where you can cast to an interface type to only require the subset of the API you actually need to call. Go is a good example of this, in fact doing the lookup at runtime…

My point is that this pattern is not object oriented programming. As for a default behavior with it, you usually would do that by either always adding the default pointer when creating the structure or calling the default whenever the pointer is NULL. In the Linux VFS for example, there are optimized functions for reading and writing, but if those are not implemented, a fallback to unoptimized functions is done at th…

> My point is that this pattern is not object oriented programming.

I think the "is/is not" question is not so clear. If you think of "is" as a whether there's a homomorphism, then it makes sense to say that it is OOP, but it can qualify as being something else too, ie. it's not an exclusionary relationaship.

Post reply on HN