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

Object-oriented techniques in C

dmitryfrank.com

Post reply on HN
Print view View original

31–40 of 74 posts

Re: Object-oriented techniques in C

#31

Post by MichaelGG »

How badly does this impact optimizations? First you add an extra function pointer for any member, even if it's not virtual. Then since you're always calling via a function pointer -- do compilers notice when fps are assigned and never modified and do inlining and so on?

Also the first technique doesn't feel like OO in any meaningful way. Defining a state object and passing it to functions is exactly what you'd do in say, a functional programming language, or even in regular old imperative code.

Re: Object-oriented techniques in C

#32

Post by dimonomid »

MichaelGG wrote: post #31

How badly does this impact optimizations? First you add an extra function pointer for any member, even if it's not virtual. Then since you're always calling via a function pointer -- do compilers notice when fps are assigned and never modified and do inlining and so on? Also the first technique doesn't feel like OO in any meaningful way. Defining a state object and passing it to functions is exactly what you'd do in…

> First you add an extra function pointer for any member, even if it's not virtual

Wrong. If some function is not virtual, there's no point to add it to vtable; so, it's just a regular function.

> Also the first technique doesn't feel like OO in any meaningful way.

Really? Of course I can be wrong, but for me, defining a state object and operate on it only through methods (i.e. functions that are given a pointer to state object) is exactly what is called an OO style.

Re: Object-oriented techniques in C

#33

Post by kbenson »

meson2k wrote: post #27
kbenson wrote: post #17

Isn't there some way to emit C from C++? Wouldn't a capability like that and using C as a host language completely bypass the need for emulating OOP in C, by just letting you write C++? That seems like it would be far more manageable, and since it's compiled, not susceptible to some of the major downsides commonly associated with the technique (in JS).

The emitted code is highly name mangled - one of the reasons why you encapsulate the C code in "extern C" https://en.wikipedia.org/wiki/Name_mangling

That seems like a problem that has quite a few possible solutions: deterministic name mangling, hinting in the source as to how the name should be mangled, an external mapping of mangling exceptions and/or rules to be used by the transpiler. None of those are mutually exclusive, all could be used together.

Re: Object-oriented techniques in C

#34

Post by halayli »

dimonomid wrote: post #11
halayli wrote: post #9

Unmaintainable and extra complexity just to emulate a paradigm that C wasn't designed for.

Again, if we use it correctly, the resulting thing is much more maintainable than the code with switch-cases instead of virtual methods, and so on. By the way, similar approach is used across the Linux Kernel: check, for example, the book "Linux Kernel Development" by Robert Love, especially the discussion on the virtual filesystem.

Every solution feels great and neat in the beginning until you wake up one day and feel sick to your stomach from the mess it has created.

Most vtable like implementations in the kernel are nothing more than struct of function pointers, and this is almost exclusively.

Re: Object-oriented techniques in C

#35

Post by dimonomid »

halayli wrote: post #34
dimonomid wrote: post #11

Earlier quoted context omitted.

Again, if we use it correctly, the resulting thing is much more maintainable than the code with switch-cases instead of virtual methods, and so on. By the way, similar approach is used across the Linux Kernel: check, for example, the book "Linux Kernel Development" by Robert Love, especially the discussion on the virtual filesystem.

Every solution feels great and neat in the beginning until you wake up one day and feel sick to your stomach from the mess it has created. Most vtable like implementations in the kernel are nothing more than struct of function pointers, and this is almost exclusively.

As nostrademons pointed out above (https://news.ycombinator.com/item?id=10261375), if you feel that some tool you've used has created mess (so that you even feel sick to your stomach), it's most likely not because the tool is bad, but because you've used it in inappropriate way.

Re: Object-oriented techniques in C

#36

Post by vonmoltke »

azdle wrote: post #29
vonmoltke wrote: post #18

Earlier quoted context omitted.

> If you don't have a C++ compiler, and you end up having to re-invent C++ in C, then maybe you should have picked the chip with decent tools. So the software engineers are the only ones on the project who get a say as to what chips get used?

No (and that isn't what he said), but surely they should get a say, right?

pslam basically did in his next paragraph:

> If this project really did require re-inventing C++ in C, it must be justified by being fairly large. In which case, a low-end ARM (Cortex M based) microcontroller would have been entirely suitable. All ARMs have multiple C++ toolchains which support them.

ARM is not entirely suitable for any application just because you have complex (for some definition of complex) software.

Re: Object-oriented techniques in C

#37

Post by pslam »

vonmoltke wrote: post #36
azdle wrote: post #29

Earlier quoted context omitted.

No (and that isn't what he said), but surely they should get a say, right?

pslam basically did in his next paragraph: > If this project really did require re-inventing C++ in C, it must be justified by being fairly large. In which case, a low-end ARM (Cortex M based) microcontroller would have been entirely suitable. All ARMs have multiple C++ toolchains which support them. ARM is not entirely suitable for any application just because you have complex (for some definition of complex) softwa…

No, but the software impact of choosing a particular piece of hardware should absolutely be part of the system design process. If it is not, then you are part of a project with bad leadership, or very, very old-fashioned architects.

It's not just ARM - there's plenty of other CPU architectures with modern Clang, GCC, or other toolchains with C++ support. Given that this is a large code base (justifying this amount of work), this cannot be a "tiny" microcontroller, as in 8 bit, and needing to run on microamps. I cannot believe that there were not C++-capable microcontrollers available which would have done the job, without breaking the bank.

Re: Object-oriented techniques in C

#38

Post by chipsy »

nostrademons wrote: post #22
TickleSteve wrote: post #2

Do NOT use these techniques please! I have experience of an early nineties project that was entirely structured like this and trust me, it ends up as a disaster. C is not meant to be OO, consequently all the tooling in editors and the like do not understand the links between classes and methods. What it ends up like is an impenetrable mess with all the mechanics of C++ exposed but being impossible to navigate. again.…

Bah. It's a tool. Just like any tool, you should have it in your toolbox, and use it when appropriate. When I hear about C programs that were a disaster because they used OO-like techniques, the operative word is usually "disaster" and not "C" or "OO". In other words, there were other things wrong with the project that had nothing to do with the selection of language or programming paradigm, like hiring inexperienced…

Seconding the idea that you don't use something like this prolifically. The point is to only go slightly past the limits of the tooling and still primarily be writing C in the style that C is best at.

For similar reasons, "cute" macro-heavy C code tends not to survive long-term, because it breaks too much tooling.

Re: Object-oriented techniques in C

#40

Post by Skunkleton »

jasode wrote: post #14
TickleSteve wrote: post #2

Do NOT use these techniques please! I have experience of an early nineties project that was entirely structured like this and trust me, it ends up as a disaster. C is not meant to be OO, consequently all the tooling in editors and the like do not understand the links between classes and methods. What it ends up like is an impenetrable mess with all the mechanics of C++ exposed but being impossible to navigate. again.…

> and trust me, it ends up as a disaster. [...] please do not do this in any project... for the sake of any who will follow you in maintaining your code! The Linux kernel has some OO techniques in C. 2-part story: https://lwn.net/Articles/444910/ https://lwn.net/Articles/446317/ I don't follow the Linux development mailing lists so I don't know if Linus Torvalds and other respected contributors regard those technique…

I would argue that the linux kernel is largely object oriented, especially in the realm of device drivers. Every subsystem that I have worked with has you fill out the equivalent of a vtable, and passes state through structs rather than globally.
Post reply on HN