Earlier quoted context omitted.
I wasn't too keen on this book. I read it hoping it would be more like the article in this post. But I felt it was more a case of someone re-inventing c++ with macros.
You mean "C with classes" ?
[dead]
OOP in C
111–120 of 149 posts
Re: OOP in C
#112Earlier quoted context omitted.
That wouldn't actually help much. In the case that there is no inheritance, using a function pointer has unnecessary overhead (pointer storage, indirect call, additional parameter). In the case of inheritance, the pointer type differs and thus the function pointer type wouldn't be compatible either.
You need to use a void* self pointer. And indirect through the vtable in all calls to virtual methods, even those that are part of the object itself. Thus, e.g. a method defined on a base class might end up calling an implementation deep in the inheritance hierarchy, that didn't even exist when the base class code was written. There's no real equivalent to this when doing simple interface inheritance, but it's very m…
[deleted]
Re: OOP in C
#113Earlier quoted context omitted.
That wouldn't actually help much. In the case that there is no inheritance, using a function pointer has unnecessary overhead (pointer storage, indirect call, additional parameter). In the case of inheritance, the pointer type differs and thus the function pointer type wouldn't be compatible either.
Last time I checked, C++ used function pointers behind the scenes to achieve virtual method dispatch.
Typically the object contains a single pointer to the vtable which is then the list of function pointers.
You can do this structure in C, but more common is the struct of function pointers which avoids a level of indirection at the cost of object size.
Re: OOP in C
#114I've seen OOP inheritance in C before. It involves a table of pointers to functions, and a derived "class" would just point to a different table.
It works, but all the machinery has to be handled manually. It's very, very easy to make a mistake. The question is, why do this? Just use C++ as "C with classes" and you'll be much better off.
Re: OOP in C
#115Earlier quoted context omitted.
It's strange that you seem to be an absolutist on this topic. What is wrong if inheritance is an elegant solution to a relatively small number of problems? Historical overuse of inheritance doesn't take away from that.
What problem is left? UI? React is showing composition wins there too.
It's just a code reuse mechanism. In some cases you can do with it what you might also do with callbacks, or yes, composition. Or in some cases inheritance might be handy.
I don't know why we need to be so judgmental about it.
I think inheritance is especially good if you have an interface (in the OO sense, like some languages use an "interface" keyword for), but you have some common or default methods, which a specific implementation may or may not override, or maybe there is some boiler plate or tedium where the most common implementation might belong in a base class. I think this is handy for something like a device driver.
Re: OOP in C
#116While I commend this effort I should say that seriously, just write C++ if possible. No matter what you do memory management is going to be your biggest enemy (I’m ignoring the aesthetic aspects like macros, function pointers, type safety, etc). Without RAII it’s just not worth it. Just choose the simpler portions of C++ and keep safe.
You can do RAII in C. You still have to define a dtor function.
https://en.wikipedia.org/wiki/Resource_acquisition_is_initia...
Re: OOP in C
#117While I commend this effort I should say that seriously, just write C++ if possible. No matter what you do memory management is going to be your biggest enemy (I’m ignoring the aesthetic aspects like macros, function pointers, type safety, etc). Without RAII it’s just not worth it. Just choose the simpler portions of C++ and keep safe.
I never have trouble with memory management in C by sticking to "grouped element architectures" with explicit lifetimes such as arenas, scratch allocators, dynamic pools, etc. RAII is mostly for "single element architectures" which IMO are not a good way to organize code because they tend to amount to thousands of unnecessary memory operations.
Re: OOP in C
#118Earlier quoted context omitted.
Anyone who disagrees with you is simply poorly read and uninformed? You cannot separate theory and practice in the way you are attempting to. It’s not just “bad books” that lead to the abuse of inheritance that is so familiar, there were (and are) broken concepts that only became visible with time. I highlighted “module” for a reason, because one of the key mistakes of practitioners was to view the element of re-use…
Your straw men fall easily. But your "snipe" doesn't even apply. I spent the two years of my masters program editing a NASA-owned LISP codebase. it wasn't huge. Maybe 100kloc. But I'm definitely not ignorant or LISP. Look, you don't like OOP, who cares? I certainly don't. But that's different than trying to explain that you have a fundamental misunderstanding. Whether you accept it or not, it's in your head now ;)
I’m too old and tired for the insult slinging anyway.
What’s my fundamental misunderstanding? What’s the straw man? Class == re-use?
I don’t hate OO by the way, it’s just not the first, only, or in my opinion best way to think about or structure code. I do think the expectations that OO would bring increased productivity, code-reuse, etc were not realised and hence why I referred to it as a “failed paradigm”. Not because it is bad from a theory perspective, but because in practice none/few of the things it was expected to deliver actually materialised. And also that the real challenges with “code reuse” are different. I have read the bad books, but also the good books.
I’ve done more OOP programming than anything else over my career, and it can be done well. I’ve also worked with and coded in extremely well written C code bases. I just can’t see the value that OOP provided over modular C. Perhaps you can enlighten me?
Re: OOP in C
#119Earlier quoted context omitted.
That wouldn't actually help much. In the case that there is no inheritance, using a function pointer has unnecessary overhead (pointer storage, indirect call, additional parameter). In the case of inheritance, the pointer type differs and thus the function pointer type wouldn't be compatible either.
Inheritance is nowadays almost considered a bad practice, in fact newer languages, such as Rust, doesn't support it, and in languages that has it (Java, C#, etc) nowadays they always tell you to prefer composition over inheritance. > using a function pointer has unnecessary overhead This is true, it's inefficient. But for a lot of application, also irrelevant at performance level, and would provide a good abstraction…
> prefer composition over inheritance
Right... There is an animal in a dog.
Re: OOP in C
#120I was doing OOP in C, back in the early ‘90s. Lotta work, but turned out great. Some of the software that I wrote back then, was still in use, 25 years later (a camera software SDK). It had to be done a certain way, because stack conventions were all over the place, back then.
In early 90s we’ve got a CD-ROM with all known genomic data from NCBI. And on the same CD there was a portable (Win, Macintosh, X Win) graphics system written in C in OOP style, named Vibrant. Portable graphics long before Java! And using that funny - and very usable - OOP style too. So, instead of studying genomes I was looking at C code, and soon was using it in a telecom project that I was doing on the side (90s were pretty hard in Russia).
https://www.ncbi.nlm.nih.gov/IEB/ToolBox/SDKDOCS/VIBRANT.HTM...
The code is pretty well written and probably can be used in a teaching environment, like the original article describes. But I am very bad in teaching…