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

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

state-machine.com

Post reply on HN
Print view View original

71–80 of 95 posts

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

#71

Post by rurban »

jcelerier wrote: post #64
rurban wrote: post #48

Earlier quoted context omitted.

OOP in C++ leads to twice as much pointer dereferencing. Just that you don't see it doesn't mean it does not exist. Look at the generated code. It sucks. The best thing in C++ is compile-time computation (ignoring the horrible template syntax). OO is not esp. well implemented.

Inlining the ctable into the object would only be faster if - you have very few objects - you have very few virtual functions If you have a lot of objects or a lot of virtual functions, things will be less likely to fit in cache which will entirely destroy your performance, by an order of magnitude when compared to a mostly-always-branch-predicted indirection. I remember experimenting with a an "inlined" version of s…

Depends. My STL in C is faster by inlining the iterator methods. With something like glib or qt double indirection would be better of course, because these can be shared then.

In my jitted ruby-like VM my methods are also copied, not referenced. Javascript also prefers copying the methods. This is usually called prototype-based OO. True prototypes copy the struct fields also, without creating classes, but copying the read-only methods only is a worthwhile OO optimization, C++ cannot do.

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

#72

Post by ahartmetz »

LAC-Tech wrote: post #13
Subsentient wrote: post #12

Earlier quoted context omitted.

C++ has plenty of issues, but it's really not that bad, especially modern C++. It's a huge language with tons of features, many of which you'll never use, but as far as writing C++, really not that bad. I've written a lot of C++ over the years, and I've also written a lot of vanilla C. I can tell you that you can definitely get a new project up and running much faster in C++ than in C.

I'm an OO programmer, and I avoid using classes in C++. The happy path seems to be to treat at C with STL + smart pointers, not C with classes.

About OO: Bundling data and behavior is a fine technique in some situations, nothing wrong with it. Sometimes, even inheritance makes sense.

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

#73

Post by tpoacher »

WalterBright wrote: post #4

If you need to do OOP in C, it's time to move to a more powerful language.

Thats's silly. OOP is a software engineering paradigm first, and language feature second.

It's like saying English doesn't have a built-in politeness pronoun, so if you need to be polite you can't use English.

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

#74

Post by mst »

heresie-dabord wrote: post #54
mst wrote: post #44

Earlier quoted context omitted.

While it's hardly a complete object system, perl's bless() operator associating a package name with a data structure, where the package is (for bless()'s purposes at least) basically just a global hash mapping method names to subroutines, was pretty much how I first got my brain around the concept. I wish more "introduction to OO" things would start by demonstrating a dispatch table and then showing how the vtable co…

> it's hardly a complete object system While other programming languages became mired in OOP dispute, opinion-battles, and all the ensuing problems[1], Perl 5's built-in OO is easy to learn and understand and makes the difficult things simple. It has been stable and effective for decades . OO is just a pattern; it can be useful or misused, some aspects are more useful than others. But the defining goalposts are moved…

Yeah, I might know a little bit about that, but I was focusing on how bless() helped me initially learn how OO worked at all. (I was after all one of the first power users of Moose, am the original author of Moo and Role::Tiny, and (re)wrote several chunks of the Mojo::Base OO system at various points as well ;)

I'm pretty glad we've mostly standardised on the M* style these days, and Object::Pad (the cpan module that will likely eventually become the template for core OO) is still pretty familiar to users of that as well.

(the days before M* style became the default were ... "fun" ... though at least it meant we got native C3 MRO support added to the perl5 VM to support my decision to use a C3 based component model when I wrote DBIx::Class)

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

#75

Post by mst »

aaaaaaaaaaab wrote: post #49
rurban wrote: post #47

Earlier quoted context omitted.

It's a measurable difference. OO in C++ must use double indirect vtable method calls, whilst this OO in C uses only one indirection. It's measurably faster. Objects are a bit larger though, cloning is a bit more expensive, but method calls are much faster and much easier to cache.

I think you're misinterpreting GP's code. It is a vtable, hence the static const . There would be a pointer in each struct "instance" to this static vtable, thus the same double indirection would occcur as in C++.

Plus this was a discussion about conceptual models and "what counts as OO", not the specific details and optimisation possibilities of the implementation.

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

#76

Post by jcelerier »

rurban wrote: post #71
jcelerier wrote: post #64

Earlier quoted context omitted.

Inlining the ctable into the object would only be faster if - you have very few objects - you have very few virtual functions If you have a lot of objects or a lot of virtual functions, things will be less likely to fit in cache which will entirely destroy your performance, by an order of magnitude when compared to a mostly-always-branch-predicted indirection. I remember experimenting with a an "inlined" version of s…

Depends. My STL in C is faster by inlining the iterator methods. With something like glib or qt double indirection would be better of course, because these can be shared then. In my jitted ruby-like VM my methods are also copied, not referenced. Javascript also prefers copying the methods. This is usually called prototype-based OO. True prototypes copy the struct fields also, without creating classes, but copying the…

Can you share some benchmarks for your STL ?

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

#77

Post by Subsentient »

gefhfff wrote: post #19
Subsentient wrote: post #12

Earlier quoted context omitted.

C++ has plenty of issues, but it's really not that bad, especially modern C++. It's a huge language with tons of features, many of which you'll never use, but as far as writing C++, really not that bad. I've written a lot of C++ over the years, and I've also written a lot of vanilla C. I can tell you that you can definitely get a new project up and running much faster in C++ than in C.

It is not that bad... Compared to c Throwing Rust into the pool

I write Rust too. I like Rust for the mostpart, though there's some issues with the language that really wind me up, mostly to do with the unsafe/safe code boundary.

If you want full control and easier interfacing with the OS, C++ is probably a little better, but Rust is definitely a little easier to work with once you learn the language.

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

#78

Post by voldacar »

ku-man wrote: post #11
WalterBright wrote: post #4

If you need to do OOP in C, it's time to move to a more powerful language.

"If you need to do OOP in C, it's time to move to a more powerful language." As long as is not C++...

The parent is the creator of the D language. It is a lot saner than C++ in my opinion, though it's not without its flaws

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

#79

Post by WalterBright »

synergy20 wrote: post #65
WalterBright wrote: post #4

If you need to do OOP in C, it's time to move to a more powerful language.

Really? Linux kernel uses extensive OOP/C.

I haven't looked at how the kernel is written. But Linus has a problem using a more powerful language - if Linux adopted one just for OOP, then it will become impossible to hold back contributors from using every last feature of that language. I can understand the reluctance to deal with that.

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

#80

Post by ncmncm »

pjmlp wrote: post #38
ncmncm wrote: post #21

Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good , it was then by definition object-oriented . Anything good had therefore to be called OO. Saying something was not actually OO (e.g. this) was taken to mean it was not good , generating spurious conflict. The fiction has largely dissipated, except among pundits and the aggressively ignorant. Meanwh…

https://microsoft.github.io/microsoft-ui-xaml > WinUI is powered by a highly optimized C++ core that delivers blistering performance, long battery life, and responsive interactivity that professional developers demand. Its lower system utilization allows it to run on a wider range of hardware, ensuring your sophisticated workloads run with ease. Apparently Microsoft does care about OOP in C++. As does Apple, https://…

I wasted time looking in those links. The WinUI page does not mention base classes (or prototypes), inheritance, or any sort of runtime binding. A "highly-optimized C++ core", in particular, does not imply OO. The std::ranges view_interface template is not OO; it uses concrete inheritance purely as a notational convenience.

Likewise the others, with one exception. The Apple driverkit page does mention base classes.

Factories, adaptors, concepts/traits/interfaces have nothing to do with OO, beyond that OO designs often also use them. OO designs define functions, too, but functions do not imply OO.

It is, in any case, meaningless to trot out apparatus system-vendors oblige programmers to use to access proprietary facilities, and equate that to programmers' interest in whatever tech is used for them. Programmers are interested in using the facilities, and are glad when whatever they are obliged to use works at all; too often it doesn't.

Post reply on HN