OOP in C inevitably leads to LOTS of pointer dereferencing. Pointer dereferencing hurts performance.
Object-Oriented Programming in C (2019) [pdf]
31–40 of 95 posts
Re: Object-Oriented Programming in C (2019) [pdf]
#32This is a good example of how a good programmer is more important than a a complex language with complex features. C lets you use OO if you want it ,and it doesn't require many more lines to do it, but it doesn't push you to always do it. Ive used this a number of times, but its always because its the right approach for the problem, not to be object oriented because the language is.
> C lets you use OO if you want it Tenuous - if you are willing to implement objects yourself then you could use C sure, but I don't think that means the language "lets you use OO". It's like you could also probably implement algebraic datatypes in C using unions and structs, but would that mean "C lets you use algebraic datatypes"? I would strongly argue no.
All our languages are Turing-complete. None actively prevent any sort of programming,
Thus, to meaningfully claim that a language supports some programming technique, it has to automate it to some appreciable degree. C manifestly does not; it automates nothing but stack frames and register allocation. Every detail is hand-coded, with every opportunity to make trivial, hard-to-spot mistakes that nothing but exhaustive testing can bring to your attention.
Re: Object-Oriented Programming in C (2019) [pdf]
#33If you need to do OOP in C, it's time to move to a more powerful language.
This to me says that C is the more powerful language. C can do what higher level languages can, in not many more lines, but higher level languages cant do the low level things C can do.
I've done OOP in C, and so have others.
It's just not worth it. Too much casting, too much scaffolding, much too brittle and error-prone. The experience is like "how much suffering can one endure."
Re: Object-Oriented Programming in C (2019) [pdf]
#34I really wish people would stop reducing OOP to classes…
Classes by themselves are just another name for abstract data types, so just being able to define classes, i.e. structures together with methods that manipulate their members is not enough to qualify as OOP. Abstract data types have a field of applicability far larger than OOP.
OOP has 2 main features, which have first appeared in SIMULA-67: inheritance and virtual functions.
I agree with the following definition for OOP as as a special kind of programming with abstract data types:
"There are two features that distinguish an object-oriented language from one based on abstract data types: polymorphism caused by late-binding of procedure calls and inheritance. Polymorphism leads to the idea of using the set of messages that an object understands as its type, and inheritance leads to the idea of an abstract class. Both are important." (Ralph E. Johnson & Brian Foote, Journal of Object-Oriented Programming, June/July 1988, Volume 1, Number 2, pages 22-35)
When virtual functions are not used, the operations can be considered as belonging to the type (a.k.a. class), not to the objects, which corresponds to the jargon used by programming with abstract data types.
When virtual functions are used, the operations are considered as belonging to the objects, not to the class, as each object may have a different implementation of a given method. This corresponds with the point of view of OOP.
I have used the SIMULA/C++ term of "virtual functions", but in some OOP languages all functions are of the kind named "virtual" in SIMULA, so the "virtual" term is not used.
Re: Object-Oriented Programming in C (2019) [pdf]
#35If you need to do OOP in C, it's time to move to a more powerful language.
There is one advantage to doing OOP in C. Once you figure it out, the mystery of how OOP works all falls away. Frankly, I didn't understand how OOP worked before doing that. None of the tutorials explained what was going on under the hood.
As an engineer, I'm never comfortable using something when I don't know how it works.
Re: Object-Oriented Programming in C (2019) [pdf]
#36OOP in C inevitably leads to LOTS of pointer dereferencing. Pointer dereferencing hurts performance.
OOP in most languages tends to lead to lots of pointer dereferencing behind the scenes. If you're lucky and it's not much worse.
Re: Object-Oriented Programming in C (2019) [pdf]
#37I think this approach is working too hard to realize Virtual Tables and Virtual Pointers. Another, different implementation is to define an array of function pointers, one function per method implemented, and then extend the array per subclass; each child class fills in its own or parents function pointers at init time.
Not an array, a struct is ok, and in C99 style it is very well readable. For example Linux Kernel style is: static const struct file_operations fops = { .open = my_open, .release = my_release, .read = my_read, .write = my_write }; that's all, very straightforward. Also there is no need to prefix the function name with &
This pattern goes back to pre-Version-7 UNIX kernels, with only minor syntactic updates. That it long predates OO demonstrates it is not OO. That does not make it any less effective, or less useful.
Re: Object-Oriented Programming in C (2019) [pdf]
#38Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good , it was then by definition object-oriented . Anything good had therefore to be called OO. Saying something was not actually OO (e.g. this) was taken to mean it was not good , generating spurious conflict. The fiction has largely dissipated, except among pundits and the aggressively ignorant. Meanwh…
https://microsoft.github.io/microsoft-ui-xaml
> WinUI is powered by a highly optimized C++ core that delivers blistering performance, long battery life, and responsive interactivity that professional developers demand. Its lower system utilization allows it to run on a wider range of hardware, ensuring your sophisticated workloads run with ease.
Apparently Microsoft does care about OOP in C++.
As does Apple,
https://developer.apple.com/metal/
https://developer.apple.com/documentation/driverkit
And Google,
https://github.com/google/oboe
https://www.tensorflow.org/api_docs
Maybe modern C++ is safe from OOP, so lets look into ranges,
https://en.cppreference.com/w/cpp/ranges
So we have factories, adaptors, concepts (aka interfaces/traits in other languages), std::ranges::view_interface as base class mixin, all stuff I can find on the Gang of Four book.
Re: Object-Oriented Programming in C (2019) [pdf]
#39Earlier quoted context omitted.
I'm an OO programmer, and I avoid using classes in C++. The happy path seems to be to treat at C with STL + smart pointers, not C with classes.
If you are not using classes, you are not using OO at all, by definition. That does necessarily not mean you are programming badly, although you might be. But restricting yourself to STL and smart pointers does very strongly resemble Java Disease. You might as well switch to Java.
Definition by whom, certainly not by CS and the innumerous SIGPLAN papers and variations on what OOP means since Simula came into the world.
Re: Object-Oriented Programming in C (2019) [pdf]
#40Earlier quoted context omitted.
C++ has plenty of issues, but it's really not that bad, especially modern C++. It's a huge language with tons of features, many of which you'll never use, but as far as writing C++, really not that bad. I've written a lot of C++ over the years, and I've also written a lot of vanilla C. I can tell you that you can definitely get a new project up and running much faster in C++ than in C.
I'm an OO programmer, and I avoid using classes in C++. The happy path seems to be to treat at C with STL + smart pointers, not C with classes.
STL has plenty of OOP concepts.