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

41–50 of 74 posts

Re: Object-oriented techniques in C

#41

Post by Skunkleton »

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…

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

But in the simple case described in op (no inheritance), that is all a class is, with the exception of some syntactic sugar.

Re: Object-oriented techniques in C

#42

Post by zeckalpha »

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 C is also not meant to be functional, but yet, there's a 400+ page book on Functional C: http://eprints.eemcs.utwente.nl/1077/02/book.pdf

Re: Object-oriented techniques in C

#43

Post by nostrademons »

kbenson wrote: post #33
meson2k wrote: post #27

Earlier quoted context omitted.

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.

It's more than that - there's extra information that's compiled alongside your runtime data structures whenever you write C++. For example, every class with virtual member functions has a vtable, and every object of such a class has a pointer to the vtable. Every time you access a virtual member function, it's indirecting through the vtable to find the particular address to call, and then calling it with the object itself as the first argument.

If you got rid of name mangling (and a few other C++ features that are besides the point), you could certainly call C++ from C. The thing is - your C calls would look exactly like what the article is suggesting. That's why it's important to learn this technique: it is what your C++ compiler is doing under the hood. Indeed, the very first C++ compilers were just preprocessors that transformed C++ syntax into the type of vtable + base class + first parameter indirection that you see here.

Re: Object-oriented techniques in C

#44

Post by MichaelGG »

dimonomid wrote: post #32
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 s…

Thanks for the correction. I had misread and thought all functions were called with member syntax.

I guess in simple cases like this the difference between OO and other styles are pointless. I'm just thinking that if I were to write it in a functional language, it'd probably a very similar API, though possibly/probably returning a new state vs modifying.

Re: Object-oriented techniques in C

#46

Post by Apocryphon »

mpweiher wrote: post #30
Apocryphon wrote: post #23

Earlier quoted context omitted.

Isn't this article's implementation of OO C based on C++?

"...badly" ;-)

Regardless of one's opinion on either, C++ and Objective-C are different OO languages. Simula 67 vs. Smalltalk and all that.

Re: Object-oriented techniques in C

#48

Post by z92 »

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

Fully agree. Ended up doing a similar approach when forced to use C instead of C++ for a data structures university project. Goal achieved, but not an experience to repeat ever again.

So how would you have done it the next time if you had to stick with C?

Re: Object-oriented techniques in C

#49

Post by z92 »

pslam wrote: post #37
vonmoltke wrote: post #36

Earlier quoted context omitted.

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…

Doing it at lowest cost is the point. Because even if you don't lower your cost, your competitors will.

Re: Object-oriented techniques in C

#50

Post by jevinskie »

meson2k wrote: post #26
pmalynin wrote: post #13

A part a of series of articles on HN: How to %feature_from_c++% in C (when you could have used C++)

or when memory constraints prevent you from using libstdc++

You can get C++ OO without linking in a whole STL. IIRC it is the C++ equivalent of -ffreestanding in C. Given that popular toolchains like GCC and IAR offer C++ support to micro controllers as small as ATtiny 8-bit AVR micros, I don't see the necessity to reimplement C++ in a hamstrung C form.

I'm currently writing a binary parser library using C++ but without the STL. I'm able to use range-based for loops, zero-cost iterators, and other features without any dependencies on a C++ STL library. After optimization, the generated code is essentially what the C equivalent with all the boilerplate would compile down to. There are plenty of OS kernels written in C++, you just have to pick the appropriate C++ subset. ;-)

Regardless, I enjoy the stricter typing in C++ that generates essentially same code as C with OO tacked on but with less boilerplate.

Post reply on HN