Object-oriented design patterns in C and kernel development

Post by MontyCarloHall » Wed, Aug 27, 2025, 8:06 PM UTC

chuckadams wrote: post #80

MontyCarloHall wrote: post #74

Earlier quoted context omitted.

Agreed, one of the biggest design mistakes in the OOP syntax of C++ (and Java, for that matter) was not making `this` mandatory when referring to instance members.

C++ and Java went for the "objects as static closures" route, where it doesn't make any sense to have a `this`. Or, they made them superficially look like static closures, which in hindsight was probably not the best idea. Anyway, Java lets you use explicit `this`, I don't recall whether C++ makes it into a footgun or not.

   void foo() {
      int x = bar + 1; // should be illegal: it can be hard to distinguish if `bar` is a local variable versus an instance member
      int y = this->bar + 1; // disambiguation is good
   }

Post by Galanwe » Wed, Aug 27, 2025, 8:18 PM UTC

1718627440 wrote: post #79

Galanwe wrote: post #77

Earlier quoted context omitted.

I don't quite agree, especially because the implicit this not only saves you from explicitly typing it, but also because by having actual methods you don't need to add the struct suffix to every function. mystruct_dosmth(s); mystruct_dosmthelse(s); vs s->dosmth(); s->dosmthelse();

My problem with implicit this is more, that you can access member variables, without it being explicit, i.e. about the callee, not about the caller. For the function naming, nothing stops you from doing the same in C: static dosmth (struct * s); s->dosmth = dosmth; That doesn't stop you from mentioning s twice. While it is redundant in the common case, it isn't in every case like I wrote elsewhere. Also this is easil…

Post by 1718627440 » Wed, Aug 27, 2025, 8:22 PM UTC

ryao wrote: post #83

1718627440 wrote: post #72

Earlier quoted context omitted.

Yeah, but the compiler implements these by adding vtables, propagating vtables values across inheritance hierarchies, adding another parameter. You claim when the compiler does this, it's OOP, but when I do it, it's not?

The entire point of OOP in every OOP language that I have ever used has been to have the language try to constrain what you can do by pushing restrictions on syntactic sugar involving objects, inheritance and encapsulation, so I would say yes. The marketing claims that people will be more productive at programming by using these.

Post by 1718627440 » Wed, Aug 27, 2025, 8:26 PM UTC

Galanwe wrote: post #84

1718627440 wrote: post #79

Earlier quoted context omitted.

My problem with implicit this is more, that you can access member variables, without it being explicit, i.e. about the callee, not about the caller. For the function naming, nothing stops you from doing the same in C: static dosmth (struct * s); s->dosmth = dosmth; That doesn't stop you from mentioning s twice. While it is redundant in the common case, it isn't in every case like I wrote elsewhere. Also this is easil…

This is not the same, you introduced dynamic function resolution (i.e.a function pointer tied to a specific instance), we are talking about static function resolution (purely based on the declared type).

Post by cherryteastain » Wed, Aug 27, 2025, 9:17 PM UTC

chuckadams wrote: post #80

MontyCarloHall wrote: post #74

Earlier quoted context omitted.

Agreed, one of the biggest design mistakes in the OOP syntax of C++ (and Java, for that matter) was not making `this` mandatory when referring to instance members.

C++ and Java went for the "objects as static closures" route, where it doesn't make any sense to have a `this`. Or, they made them superficially look like static closures, which in hindsight was probably not the best idea. Anyway, Java lets you use explicit `this`, I don't recall whether C++ makes it into a footgun or not.