Object-Oriented Programming in C (2019) [pdf] • Hacker News Board

Re: Object-Oriented Programming in C (2019) [pdf]

#91

Post by ncmncm » Tue, Sep 07, 2021, 9:34 AM UTC

pjmlp wrote: post #90

ncmncm wrote: post #89

Earlier quoted context omitted.

That was not the reason. But it was the reason that C, as standardized, adopted several C++ innovations first.

It was definitly the reason, by 1992 it was impossible to buy a C compiler that also did not had a C++ one in the box. Also why Apple moved from Object Pascal to C++ on MPW.

None of those C or C++ compilers came from Bell Labs, or were on UNIX tapes from Bell Labs. I used Cfront on Apollo machines in the '80s. Effectively nobody was using Cfront by 1992.

Apple, particularly, was not strongly influenced by Bell Labs or UNIX. Apple A/UX–a UNIX for Macintosh, a niche product from that period–shipped without a C++ compiler. MPW in 1992 shipped without a C++ compiler.

Re: Object-Oriented Programming in C (2019) [pdf]

#92

Post by pjmlp » Tue, Sep 07, 2021, 11:57 AM UTC

ncmncm wrote: post #91

pjmlp wrote: post #90

Earlier quoted context omitted.

It was definitly the reason, by 1992 it was impossible to buy a C compiler that also did not had a C++ one in the box. Also why Apple moved from Object Pascal to C++ on MPW.

None of those C or C++ compilers came from Bell Labs, or were on UNIX tapes from Bell Labs. I used Cfront on Apollo machines in the '80s. Effectively nobody was using Cfront by 1992. Apple, particularly, was not strongly influenced by Bell Labs or UNIX. Apple A/UX–a UNIX for Macintosh, a niche product from that period–shipped without a C++ compiler. MPW in 1992 shipped without a C++ compiler.

So what? Did you missed the part about compiler vendors?

Those were the ones that cared about C outside UNIX.

Bell Labs also had nothing to say to what happened to their code when they set it free.

And Zortech was one of the first vendors to move away from CFront.

Re: Object-Oriented Programming in C (2019) [pdf]

#93

Post by pjmlp » Tue, Sep 07, 2021, 12:01 PM UTC

ncmncm wrote: post #87

pjmlp wrote: post #82

Earlier quoted context omitted.

WinUI uses COM/WinRT, COM is an OOP ABI, and WinRT is basically COM v2, with TLB libraries replaced with .NET type system and types must support IInspectable in addition to IUnknown. Are you going to argue .NET isn't OOP? As for the rest, OOP doesn't imply inheritance, BETA and SELF are good examples of OOP without inheritance.

Nobody uses Beta or Self. And, no matter how much alphabet soup MS throws at its long, rolling UI debacle, it demonstrates nothing about general programmers' current level of interest in OO.

Arguing against industry usage of OOP, including C++20 own standard library, trying to fit one's little window of the world, also doesn't help.

Re: Object-Oriented Programming in C (2019) [pdf]

#94

Post by kitkat_new » Tue, Sep 07, 2021, 4:05 PM UTC

_old_dude_ wrote: post #55

kitkat_new wrote: post #53

Earlier quoted context omitted.

saying OOP is only useless and counter productive is as short sighted as saying it is the golden hammer for everything. PS: WinUI apps use plenty OOP

It's not what i've said, OOP is great for creating APIs like WinUI, not great for writing applications

and WinUI apps are applications, and - as said - OOP is used by them, see e.g. the reference architecture guide

Re: Object-Oriented Programming in C (2019) [pdf]

#95

Post by ribit » Sat, Sep 11, 2021, 9:22 AM UTC

adrian_b wrote: post #34

ribit wrote: post #15

I really wish people would stop reducing OOP to classes…

Classes by themselves are just another name for abstract data types, so just being able to define classes, i.e. structures together with methods that manipulate their members is not enough to qualify as OOP. Abstract data types have a field of applicability far larger than OOP. OOP has 2 main features, which have first appeared in SIMULA-67: inheritance and virtual functions. I agree with the following definition for…

Well, "classes" in the mainstream programming are data types that are bound by an inheritance hierarchy. Which is exactly the problem of the "popular OOP": polymorphism (behavior) is constrained by inheritance. You cannot add a behavior to an object if that object is not part of the correct hierarchy.

Once you separate type hierarchy and behavior, you get a much more flexible system. That's what newer languages (Rust, Swift and co.) do. I think the reason why "classes" are so popular has to do with compiler technology — type hierarchies can implement polymorphism very efficiently via vtables, and folks jumped on the opportunity of having high-level abstractions with high performance (instead of doing expensive lookups associated with earlier per-instance polymorphism). But as the compiler tech and understanding of programming language theory have progressed, these limitations are not necessary for good performance anymore, in fact, they become limiting.