Sure, you can totally ignore cmath and string, but you can't ignore iostream and namespace std; unless you don't want to do anything useful at all with your program, which are GUESS WHAT compiled lists of functions and possibly some classes or class references. Nice job completely avoiding the use of methods other than main. So much for avoiding OOP.
Also I looked up delegates, and they are as OOP as it gets, they're essentially Function Pointers. They're designed for use with multiple class methods that might have the same signature, to speed up programming and make code more efficient. They have zero to do with procedural programming.
You can keep saying C++ was designed to provide and take advantage of an archaic and obsolete programming style if you want, and I'll tell you that it was designed to provide and take advantage of something actually useful.
If you don't understand how to work with OOP, you will be USELESS in the real world.
dude seriously....
Let's ignore for a second what can be avoided in c++ or what you shouldn't call 'useless' that has no touch with i/o, a class can be done in procedural code, because you can in fact write keyword class, it's just very hard work and you are pretty much bound to end up with something less good than the original one.
And I never said delegates are procedural they are though in very large use for event oriented.
Yes they are like function pointers but they are so much more too.
They can be used as magic little triggers.
This is the concept of event oriented, I do something, a function triggers, it does something, another triggers.
It's pretty much enough that you go ahead and create a button in c# and connect it to some function, then in that function you force-push another button hence triggering another and it's already event oriented.
That's really all there is to it.
Yes delegates can be used as plain function pointers, resolving problems such as 2 classes depending on each other, but again, it can be your gateway to the OE world
I however don't see how this remotely makes things speed up, in fact by merely using classes you already say "Speed? who needs that!"
Which is why c++ once again is great, as while you can do some things with classes, you can keep your vital parts of the program procedural, and not having a garbage collector which can really kick in at the worse of times is a yet anther good thing.
(Unless you enjoy not having to use delete[], and hence avoiding a lot of run-time bugs)
And you can keep saying that procedural programming is obsolete, but there is a pretty good reason operation systems and anything low-level and vital to any machine is not making use of OOP.
That's without mentioning that you'd actually be happier with assembly than with C if there is a rocket you need to shoot down.
It's all about the fact that Classes make it easier for the programmer but the machine itself is being forced into reading and executing a lot more lines than it should.
And your last line is just... too incorrect.
There are 2 types of jobs out there (Sooner or later I'll have to choose and I think I'll go with oop despite my affection to procedural and performance)
1. low-level - drivers, embedded, operating systems, anything you need to run FAST
2. high-level - Anything that runs on top of a low-level program and hence can be slower.
The first pays a lot more but a lot harder to do, a lot more tedious and takes a lot more time.
For example A simple recursive function searching for values in leafs of a given tree and returns the sum.
In C this takes about 7 rows, in assembly this takes about 60.
Which is faster? the assembly one.
Why? because when you translate 7 rows in C into assembly you are going to see a lot of code that just doesn't fit with your current program and could have been removed but since every line you write in C not to mention C# has to be "1 size fits them all" then juggling a few extra registers is needed.
And that sir is why procedural programing is NEVER going out of the system.
Discord
Light Style