I pretty much completely agree with hanst.
The only issue with procedural is that it isn't flexible. So as the needs of the program change (or the scope of the program broadens), it becomes more and more work to maintain. You end up slapping in half-hearted patches to add new features and before long you have a tangled mess.
On the plus side, writing procedural code is much faster and easier than writing OOP code.
So it works out that procedural is generally better for quick programs and/or programs with a short life, and OOP is generally better for big investment/long term projects.
|And I often read that unless your going pure OOP, it's not OOP,|
I can see why people would say that... there's a sort of truth to it, but it's a very loaded way to phrase the idea. IMO the defining characteristic of OOP is encapsulation. And if your classes are not properly encapsulated, then it really isn't
But that doesn't mean you can't have (or use) encapsulated classes in an otherwise procedural program. You said yourself you use strings/vectors/etc where appropriate... so then guess what... you're taking advantage of OOP. Those classes are encapsulated.
Those classes are also great examples of why OOP is so useful. When you learn to write classes that focus on one very specific thing, and don't reach outside that one thing... you'll find that they are much easier to use, using them is much less error prone, and you'll be able to use them more often.
|Why is there so much pressure to use strict OOP? |
Depends where the pressure is coming from. If it's some dude on a message board, he probably is just opinionated and/or dumb.
If it's coming from an employer, it's probably because they need things to be OOP so their codebase can be maintainable (lots of very big, very long-life programs in the professional world... maintainability is HUGE).