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

C Object Oriented Programming (2014)

nullprogram.com

Post reply on HN
Print view View original

11–20 of 61 posts

Re: C Object Oriented Programming (2014)

#11

Post by o11c »

Hmm, I don't have much to disagree with for this link, unlike many things from that site.

One minor point - the method implementations should not be `static`, so that you can support further subclassing and reuse the base class implementations.

Note that to support both virtual and non-virtual method binding, the dispatcher also needs to be exported (with the same signature). This is already the case in the linked code but a point isn't made of it; it can be tempting to abuse `inline` but remember that is primarily about visibility [1].

It also doesn't mention how to implement `dynamic_cast` (practically mandatory for multimethod-like things), which can be quite tricky, especially in the multiple-inheritance case and/or when you don't know all the subclasses ahead of time and/or when you have classes used in across shared libraries. There are cases where you really do need multiple vtables.

Virtual inheritance, despite its uses, is probably a mistake so it's fine that it ignores that.

[1]: https://stackoverflow.com/a/51229603/1405588

Re: C Object Oriented Programming (2014)

#13

Post by rileyphone »

o11c wrote: post #11

Hmm, I don't have much to disagree with for this link, unlike many things from that site. One minor point - the method implementations should not be `static`, so that you can support further subclassing and reuse the base class implementations. Note that to support both virtual and non-virtual method binding, the dispatcher also needs to be exported (with the same signature). This is already the case in the linked co…

Is there anything you need multimethods for that can't be patched with visitors and other design patterns? They have always seemed to me like a neat feature that are devilishly tricky to implement and difficult to reason about for the average programmer.

Re: C Object Oriented Programming (2014)

#14

Post by thesuperbigfrog »

pjmlp wrote: post #4
naitgacem wrote: post #2

Excellent writeup and straight to the point. As the author demonstrated one can get quite a lot of OOP constructs using C primitives. what seems to be impossible to implement (as least to me) was something like interfaces, a way to decouple in a way such that high level functions don't need to know about the low level building blocks.

We used to have books about it, and stuff like COM, SOM, CORBA also support C, which is exactly what you're referring to. Regarding books, here is one from 1993, https://www.mclibre.org/descargar/docs/libros/ooc-ats.pdf

Links to Axel-Tobias Schreiner's books:

https://www.cs.rit.edu/~ats/books/

"Object-Oriented Programming with ANSI-C" (English):

https://www.cs.rit.edu/~ats/books/ooc.pdf

"Objekt-orientierte Programmierung mit ANSI-C" (German):

https://www.cs.rit.edu/~ats/books/ooc_de.pdf

Re: C Object Oriented Programming (2014)

#16

Post by andai »

>Object oriented programming, polymorphism in particular, is essential to nearly any large, complex software system. Without it, decoupling different system components is difficult. (Update in 2017: I no longer agree with this statement.)

The author doesn't seem to elaborate on this. I was taught OOP in university and then promptly learned that it's frowned upon in performance sensitive code, which is my main interest in programming.

(And that it apparently doesn't even achieve its stated goal of making the code easier to understand -- I've certainly had the experience of wading through a deep inheritance hierarchy (or call stack) looking for the "actual code that actually runs"...)

I'd love to hear an elaboration on that idea (OOP is essential for decoupling components) and its counterargument (decoupling can apparently be done just fine without OOP?).

Re: C Object Oriented Programming (2014)

#17

Post by tus666 »

andai wrote: post #16

>Object oriented programming, polymorphism in particular, is essential to nearly any large, complex software system. Without it, decoupling different system components is difficult. (Update in 2017: I no longer agree with this statement.) The author doesn't seem to elaborate on this. I was taught OOP in university and then promptly learned that it's frowned upon in performance sensitive code, which is my main interes…

> is essential to nearly any large, complex software system

> in performance sensitive code

Those two things are not the same.

Re: C Object Oriented Programming (2014)

#18

Post by o11c »

rileyphone wrote: post #13
o11c wrote: post #11

Hmm, I don't have much to disagree with for this link, unlike many things from that site. One minor point - the method implementations should not be `static`, so that you can support further subclassing and reuse the base class implementations. Note that to support both virtual and non-virtual method binding, the dispatcher also needs to be exported (with the same signature). This is already the case in the linked co…

Is there anything you need multimethods for that can't be patched with visitors and other design patterns? They have always seemed to me like a neat feature that are devilishly tricky to implement and difficult to reason about for the average programmer.

You don't need multimethods per se, but you need something and `dynamic_cast` is usually easiest (and with reasonable restrictions, most efficient).

Overloaded operators is a major category of problem here. The "which subclass (if any) is more derived" might be done by the compiler proper, but that still needs to use the cast internally. And of course if you ignore operator overloading, you're just pulling a Java and mandating extra verbosity; the user's problem still has to be solved the exact same way.

(most other use cases for multimethods I don't find compelling)

Re: C Object Oriented Programming (2014)

#19

Post by randomdata »

andai wrote: post #16

>Object oriented programming, polymorphism in particular, is essential to nearly any large, complex software system. Without it, decoupling different system components is difficult. (Update in 2017: I no longer agree with this statement.) The author doesn't seem to elaborate on this. I was taught OOP in university and then promptly learned that it's frowned upon in performance sensitive code, which is my main interes…

Central to OOP is message passing between objects. Few languages utilize message passing, so it seems you can decouple components without OOP just fine.

Re: C Object Oriented Programming (2014)

#20

Post by billforsternz »

tus666 wrote: post #17
andai wrote: post #16

>Object oriented programming, polymorphism in particular, is essential to nearly any large, complex software system. Without it, decoupling different system components is difficult. (Update in 2017: I no longer agree with this statement.) The author doesn't seem to elaborate on this. I was taught OOP in university and then promptly learned that it's frowned upon in performance sensitive code, which is my main interes…

> is essential to nearly any large, complex software system > in performance sensitive code Those two things are not the same.

The question you're responding too already makes it clear those things are quite different, perhaps even orthogonal.
Post reply on HN