If you need to do OOP in C, it's time to move to a more powerful language.
As an engineer, I'm never comfortable using something when I don't know how it works.
I wish more "introduction to OO" things would start by demonstrating a dispatch table and then showing how the vtable concept maps onto that, I suspect it would make things significantly clearer to a bunch of people as they learn.
While other programming languages became mired in OOP dispute, opinion-battles, and all the ensuing problems[1], Perl 5's built-in OO is easy to learn and understand and makes the difficult things simple. It has been stable and effective for decades.
OO is just a pattern; it can be useful or misused, some aspects are more useful than others. But the defining goalposts are moved all the time. They tend to follow the hype machine.
[1] Members of the Perl community know that OO discussions have become harsh there too.
I'm pretty glad we've mostly standardised on the M* style these days, and Object::Pad (the cpan module that will likely eventually become the template for core OO) is still pretty familiar to users of that as well.
(the days before M* style became the default were ... "fun" ... though at least it meant we got native C3 MRO support added to the perl5 VM to support my decision to use a C3 based component model when I wrote DBIx::Class)
It's like saying English doesn't have a built-in politeness pronoun, so if you need to be polite you can't use English.
As long as is not C++...
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.
Throwing Rust into the pool
If you want full control and easier interfacing with the OS, C++ is probably a little better, but Rust is definitely a little easier to work with once you learn the language.
Of course, so is D...
If you need to implement virtual tables and function pointers, you'd use C++ - there's no need to reinvent the wheel.
Besides software engineering is about focusing on the intrinsic complexity, and using languages and tools to mitigate the incidental complexity.
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."