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

91–100 of 224 posts

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

#91

Post by josefx »

MontyCarloHall wrote: post #82
chuckadams wrote: post #80

Earlier quoted context omitted.

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.

Both languages let you use explicit `this` but don’t mandate it. The “static closure” approach is great. I don’t like having to explicitly pass `this` as a parameter to every method call as in the OP (or worse, the confusing Python approach of forcing `self` to be explicitly written in every non-static method signature but having it be implicitly passed during method calls). What I don’t like is being able to referen…

> int x = bar + 1; // should be illegal: it can be hard to distinguish if `bar` is a local variable versus an instance member

If it was this->bar it could be a member, it could also be a static variable. A bar on its own could be local or it could be in any of the enclosing scopes or namespaces. Forcing "this" to be explicit doesn't make the code any clearer on its own.

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

#92

Post by jcelerier »

cherryteastain wrote: post #90
chuckadams wrote: post #80

Earlier quoted context omitted.

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.

this in C++ is just a regular pointer, it has no special footguns, just the typical ones you have with pointers in general

that's not really true - unlike a regular pointer, `this` is not allowed to be null, thus removing `if(this == nullptr)` is always a valid optimization to do.

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

#93

Post by bitwize »

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?

Because Objective-C does not have foo.bar() style method calls and that's what everybody else uses and wants.

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

#94

Post by teo_zero »

ryao wrote: post #68
naasking wrote: post #20

Earlier quoted context omitted.

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

Object oriented programming implies certain contracts that the compiler enforces that are not enforced with data abstraction. Given that object oriented programming and data abstraction two live side by side in C++, we can spot the differences between member functions that have contracts enforced, and members function pointers that do not. Member functions have an implicit this pointer, and in a derived class, can ca…

> Object oriented programming implies certain contracts that the compiler enforces

Sorry, but where did you got this definition from? I've always thought OOP as a way of organizing your data and your code, sometimes supported by language-specific constructs, but not necessarily.

Can you organize your data into lists, trees, and hashmaps even if your language does not have those as native types? So you can think in a OO way even if the language has no notion of objects, methods, etc.

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

#95

Post by hhdknddkkjd »

jcelerier wrote: post #92
cherryteastain wrote: post #90

Earlier quoted context omitted.

this in C++ is just a regular pointer, it has no special footguns, just the typical ones you have with pointers in general

that's not really true - unlike a regular pointer, `this` is not allowed to be null, thus removing `if(this == nullptr)` is always a valid optimization to do.

Only in so much that this being null is UB, but in the real world it very much can be null and programs will sometimes crash deep inside methods called on nullptr.

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

#97

Post by teo_zero »

1718627440 wrote: post #28
PhilipRoman wrote: post #22

Earlier quoted context omitted.

Field inheritance is surprisingly natural in C, where a struct can be cast to it's first member.

Note that you only need to cast for an upcast. To access the first member, you wouldn't need to cast. It would be nice though, if syntax like the following would be supported: struct A { int a; }; struct B { int b; struct A a; }; void foo (struct A * a) { struct B * b; &b->a = pa; } struct B b; foo (&b.a);

In what scenario would this be useful? If foo() takes a struct A, it should be more generic and have no knowledge about the more specialized struct B.

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

#98

Post by cherryteastain »

jcelerier wrote: post #92
cherryteastain wrote: post #90

Earlier quoted context omitted.

this in C++ is just a regular pointer, it has no special footguns, just the typical ones you have with pointers in general

that's not really true - unlike a regular pointer, `this` is not allowed to be null, thus removing `if(this == nullptr)` is always a valid optimization to do.

It absolutely is allowed to be null:

    #include 
    struct Foo {
      void bar() {
        std::cout bar();
    }
will print 0

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

#100

Post by Krssst »

cherryteastain wrote: post #98
jcelerier wrote: post #92

Earlier quoted context omitted.

that's not really true - unlike a regular pointer, `this` is not allowed to be null, thus removing `if(this == nullptr)` is always a valid optimization to do.

It absolutely is allowed to be null: #include struct Foo { void bar() { std::cout bar(); } will print 0

This is undefined behavior in my understanding, it just happens to work until it doesn't.

I wouldn't be surprised if any null check against this would be erased by the optimizer for example as the parent comment mentioned. Sanitizers might check for null this too.

Post reply on HN