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

21–30 of 61 posts

Re: C Object Oriented Programming (2014)

#21

Post by WalterBright »

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…

I've also seen template hierarchies so deep it was a major effort trying to figure out which template did anything besides forward to another template.

Re: C Object Oriented Programming (2014)

#22

Post by bryancoxwell »

miuramxciii wrote: post #5
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.

Yes, You can. The entire Linux device interface, to name just one example, if full of interfaces. The way to accomplish this is via pointer to functions, and to have it as an object, have these pointer to functions grouped in a struct. GTK/Glib is notably full of these interfaces too.

libusb is a good reference for this as well, and well documented.

Re: C Object Oriented Programming (2014)

#23

Post by DontchaKnowit »

WalterBright wrote: post #21
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…

I've also seen template hierarchies so deep it was a major effort trying to figure out which template did anything besides forward to another template.

Ugh yes. This has beeb my experience with Java code in large corporate projects. Just endless layers of seemingly pointless abstraction

Re: C Object Oriented Programming (2014)

#24

Post by whatsakandr »

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…

I've found OOP can increase coupling. I actually have this problem at work. Say I have class A and B. I could write `int x = A:FunctionOfAandB(B b)`, but in this case. So now A depends on B.

It would be much preferable to have free function of A and B. A and B are no longer dependent on each other, just the function to compute the result dependent on A and B.

IMO: The real thing of value OOP provides is calling with object.method. A lot of OOP code looks like `void obj.mutate()`. If you pulled that to what's really happening in "procedural" syntax, `mutate(obj)`, that exposes it for the bad code it is.

Re: C Object Oriented Programming (2014)

#26

Post by andai »

whatsakandr wrote: post #24
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…

I've found OOP can increase coupling. I actually have this problem at work. Say I have class A and B. I could write `int x = A:FunctionOfAandB(B b)`, but in this case. So now A depends on B. It would be much preferable to have free function of A and B. A and B are no longer dependent on each other, just the function to compute the result dependent on A and B. IMO: The real thing of value OOP provides is calling with…

>The real thing of value OOP provides is calling with object.method. A lot of OOP code looks like `void obj.mutate()`. If you pulled that to what's really happening in "procedural" syntax, `mutate(obj)`, that exposes it for the bad code it is.

I'm confused here, are you saying there is value in the object.method() syntax? D language for example has Uniform Function Call Syntax[0] where f(x) can be written as x.f()

(I missed this syntax in C, and tried to approximate it by putting functions in structs, but you still have to pass the caller as an arg so it ends up being player.update(player) which looks stupid, so at that point player_update(player) seems an acceptable alternative)

Later you say obj.mutate() is bad code, are you referring only to methods which mutate the object?

[0] https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...

Re: C Object Oriented Programming (2014)

#27

Post by andai »

randomdata wrote: post #19
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.

>Few languages utilize message passing

Yet most of them call themselves object-oriented!

I'm reminded of the Alan Kay quote, "I invented the term object-oriented, and I can tell you that C++ wasn't what I had in mind."

Re: C Object Oriented Programming (2014)

#28

Post by alex_smart »

nanolith wrote: post #10

One advantage to this approach is that there is less compiler magic going on. I use a similar approach, but I prefer using type safe upcasting or model checked downcasting via inline functions or explicit references to base members, instead of direct C style casting. This also makes it easier to develop a uniform resource management strategy with allocator abstraction. Being able to easily switch between tuned bucket…

The biggest advantage of C-style polymorphism vs, say, C++ is that it actually offers much better encapsulation.

Having private methods declared in the header file which is supposed to be the public contract for the class is such an anti-pattern. And the usual solutions offered for this problem are ugly in their own right (*pImpl).

I only properly learnt to appreciate the power and beauty of OOP by reading people’s C code.

Re: C Object Oriented Programming (2014)

#29

Post by alex_smart »

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.

When you read or write from a FILE in C, do you know or have to care about whether the FILE comes from disk, a pipe, a CD drive, or a device driver or a network mounted drive? What do you think FILE is if not an interface?

Re: C Object Oriented Programming (2014)

#30

Post by alex_smart »

andai wrote: post #27
randomdata wrote: post #19

Earlier quoted context omitted.

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

>Few languages utilize message passing Yet most of them call themselves object-oriented! I'm reminded of the Alan Kay quote, "I invented the term object-oriented, and I can tell you that C++ wasn't what I had in mind."

Is Smalltalk’s message passing really all that different from methods from other OOP languages? Seems like quite an arbitrary distinction to me.
Post reply on HN