Object-oriented techniques in C • Hacker News Board

Re: Object-oriented techniques in C

#51

Post by kbenson » Wed, Sep 23, 2015, 12:37 AM UTC

nostrademons wrote: post #43

kbenson wrote: post #33

Earlier quoted context omitted.

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 i…

Yes, so while this technique would be harder to adopt for a library, or at least harder on the users, for an application where you don't really need to worry about people using C calling into your code, it would be fairly useful. A short HOWTO on how to call from C using the necessarily included and emulated C++ vtable bits would make calling in from C possible and easier where required, but you could still reap the benefits of non-C features while sticking with a C toolchain at the lowest level.

Re: Object-oriented techniques in C

#52

Post by nostrademons » Wed, Sep 23, 2015, 12:59 AM UTC

kbenson wrote: post #51

nostrademons wrote: post #43

Earlier quoted context omitted.

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 i…

Yes, so while this technique would be harder to adopt for a library, or at least harder on the users, for an application where you don't really need to worry about people using C calling into your code, it would be fairly useful. A short HOWTO on how to call from C using the necessarily included and emulated C++ vtable bits would make calling in from C possible and easier where required, but you could still reap the…

Usually an 'extern "C" { .... }' declaration is easier if you control the C++ library code.

Re: Object-oriented techniques in C

#53

Post by kbenson » Wed, Sep 23, 2015, 1:19 AM UTC

nostrademons wrote: post #52

kbenson wrote: post #51

Earlier quoted context omitted.

Yes, so while this technique would be harder to adopt for a library, or at least harder on the users, for an application where you don't really need to worry about people using C calling into your code, it would be fairly useful. A short HOWTO on how to call from C using the necessarily included and emulated C++ vtable bits would make calling in from C possible and easier where required, but you could still reap the…

Usually an 'extern "C" { .... }' declaration is easier if you control the C++ library code.

I see what's being talked about now. I misinterpreted meson2k's original reply, so haven't really been on the same page as you or him.

If current C++ to C transpilers don't handle naming well, that's a problem that should be worked on.

Re: Object-oriented techniques in C

#54

Post by jjoonathan » Wed, Sep 23, 2015, 2:00 AM UTC

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" ;-)

Method hashes (ObjC) != Vtables (C++). The former allows runtime introspection and modification that the latter doesn't, and the latter allows performance that the former doesn't.

Re: Object-oriented techniques in C

#55

Post by __david__ » Wed, Sep 23, 2015, 2:04 AM UTC

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).

That used to be the only way to compile C++: https://en.wikipedia.org/wiki/Cfront

Re: Object-oriented techniques in C

#56

Post by com2kid » Wed, Sep 23, 2015, 2:24 AM UTC

pslam wrote: post #10

openasocket wrote: post #3

This seems to just seems to be replicating the functionality of C++ in C. The only reason he gives for not using C++ is lack of C++ compilers for embedded CPUs. I think a better approach for the long term would be to use a C++ -> C transpiler (as much as I hate that word).

I'm saddened by the author going to this trouble. Embedded cpu selection doesn't happen in isolation - or at least, it shouldn't. The available tools are a large part of why you would pick chip A over chip B. 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. If this project really did require re-inventing C++ in C, it must be j…

Those low end cortex M's tend to have C++2003.

I am kinda-sorta happy to have C++ at all.

I think.

Re: Object-oriented techniques in C

#57

Post by gnuvince » Wed, Sep 23, 2015, 3:33 AM UTC

openasocket wrote: post #3

This seems to just seems to be replicating the functionality of C++ in C. The only reason he gives for not using C++ is lack of C++ compilers for embedded CPUs. I think a better approach for the long term would be to use a C++ -> C transpiler (as much as I hate that word).

> use a C++ -> C transpiler (as much as I hate that word)

Why not just use the word "compiler"?

Re: Object-oriented techniques in C

#58

Post by ant6n » Wed, Sep 23, 2015, 5:05 AM UTC

gnuvince wrote: post #57

openasocket wrote: post #3

This seems to just seems to be replicating the functionality of C++ in C. The only reason he gives for not using C++ is lack of C++ compilers for embedded CPUs. I think a better approach for the long term would be to use a C++ -> C transpiler (as much as I hate that word).

> use a C++ -> C transpiler (as much as I hate that word) Why not just use the word "compiler"?

I've encountered this here recently as well, the belief that a 'compiler' has to target machine code. When really a compiler is just a translator from one program language to another.

Re: Object-oriented techniques in C

#59

Post by vaskebjorn » Wed, Sep 23, 2015, 5:06 AM UTC

"The danger in trying to force object-oriented concepts onto a C base is to get an inconsistent construction, impairing the software development process and the quality of the resulting products. A hybrid approach yields hybrid quality. This is why serious reservations may be voiced about the object-oriented extensions of C described in chapter 20. To benefit from object-oriented techniques, one must use a consistent framework, and overcome the limitations of languages such as Fortran or C which regardless of their other characteristics -- were designed for entirely different purposes." Bertrand Meyer, Object-oriented Software Construction, 1988.

Re: Object-oriented techniques in C

#60

Post by Qwertious » Wed, Sep 23, 2015, 5:32 AM UTC

openasocket wrote: post #3

This seems to just seems to be replicating the functionality of C++ in C. The only reason he gives for not using C++ is lack of C++ compilers for embedded CPUs. I think a better approach for the long term would be to use a C++ -> C transpiler (as much as I hate that word).

Honestly, creating an object-oriented version of C that's not C++ would likely result in a language better than C++. C++ is not a particularly good language.