Object-oriented techniques in C • Hacker News Board

Re: Object-oriented techniques in C

#71

Post by EliRivers » Wed, Sep 23, 2015, 1:03 PM UTC

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.

I once met a software engineer who was able to write code that was, and remained, maintainable. Crazy, right.

Re: Object-oriented techniques in C

#72

Post by evacchi » Wed, Sep 23, 2015, 4:58 PM UTC

ant6n wrote: post #58

gnuvince wrote: post #57

Earlier quoted context omitted.

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

and even if compilers were those that generate machine code (and they're not), what's wrong with (source-to-source) translator?

Re: Object-oriented techniques in C

#73

Post by douche » Wed, Sep 23, 2015, 5:48 PM UTC

ant6n wrote: post #58

gnuvince wrote: post #57

Earlier quoted context omitted.

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

Too many people that are locked into the JS mental institution all the time?

Re: Object-oriented techniques in C

#74

Post by deathanatos » Wed, Sep 23, 2015, 5:50 PM UTC

exDM69 wrote: post #69

deathanatos wrote: post #65

Earlier quoted context omitted.

IIRC, MD5 (and probably the other hashs) are implemented in exactly this form in OpenSSL. I can't really think of a more straightforward way to implement CRC32, frankly, especially assuming that maybe you don't want to force the entire buffer to be present. If you did, you could `uint32_t crc32(unsigned char * buffer, size_t len);` — but you can implement that function in terms of the interface in the article, and if…

CRCs or MD5 or other hash sums don't require inheritance or other OO tricks or even constructors or destructors (apart from zero-initialization). The state is just a single integer. For other hashes, the state might be slightly more complicated but there's still no need for fancy OO. If you want to build a system where you can change the hash function at runtime, you might need some kind of interface or inheritance.…

> CRCs or MD5 or other hash sums don't require inheritance or other OO tricks

Given some of the other comments, I think this ought to be stressed though… OO doesn't strictly require inheritance, or vtables. A fair number of classes in the C++ STL don't use those features, for example.

It's not that the state is a single integer, either, it's that the concept of a state exists; having a separate type (with the functions surrounding that separate type) exist to embody that concept, and can change a function from an ambiguous "what goes in this uint32_t arg?" to a very obvious md5_state_t.

> or even constructors or destructors (apart from zero-initialization).

Just a nit: MD5 requires initialization that is more than just zero-initialization.

> probably give better performance because compiler optimizations can take place (virtual calls tend to prevent many optimization tricks).

This is about the most concrete argument against vtables (but hardly against OO in general) thus far, and I'd still love more explanation: what makes a branch more optimizable than following a pointer?