This is fine if you do not plan to share your work with others, but it's not well-written C++. It will bite you later on. It's best to learn the C++ way of doing things. It will save you so much time and headache. Don't use character arrays, use strings. Don't use C arrays, use std::vector or std::array. Don't write your own lists or sets, use std::list/set or std::unordered_list/set. Don't use strcat when std::string operator + exists. Etc.

I personally rarely use smart pointers or make_shared/make_unique these days. I just don't need pointers. Most of the time allocation can be done without them, and when I need to pass things around I use references. There are exceptions for C APIs for cross-platform/cross-compiler work, of course. And sometimes library code needs it, ofc.

The STL and <algorithm> are your friend. They solve so many problems in a very elegant way. Learning them should be a priority.

I'd go easy on the OOP elements unless you know OOP programming very well. Just using classes as containers for data and functions is more than fine for C++ most of the time.

Writing your own templates can be a bit of a footgun until you understand them. Feel free to put that off awhile.

Don't mess with volatile and asm unless you are 100% sure that what you're doing needs it.

Also: Be cautious with use of auto. A bit here and there is fine, but too much and code can become unreadable. C++ is a typed language for a reason.

Newer languages and modern C++ favor composition instead. You define interfaces that provide some well-defined capability, and then you write things that wrap the interfaces to provide additional functionality. In C++ you can use templates to do this without any runtime overhead. In C, you can either use preprocessor macros (ouch) or you can build your own vtables. The vtable approach adds virtual method invocations all over the place, so it's not zero cost.

The C++ approach actually isn't zero-cost either: You can end up having many copies of the same template logic, which blows up your instruction cache. One of the big innovations of swift was to avoid that. As far as I know, Rust macros and "go generate" produce binaries that are closer to the C++ approach.

Anyway, especially for emulators, you should look into getting good with C++ template meta programming, or just learn rust and then use its implementation of generics. Both approaches will let the compiler inline the heck out of stuff that ends up in the inner loop. In particular, clang + gcc are both good at constant propagation.

One problem with jumping straight from C to rust is that you basically have to already be able to write stable C++ code in order to get it to compile at all. The borrow checker moves subtle but common C++ errors from runtime to compile time. If you have a lot of experience with C already, the jump might be OK.

(edit: I should add that C++ isn't standing still, and there are lots of cool efforts to backport the good ideas from Rust to it. Systems language competition is a good thing, and they're my two favorite languages!)

1) The major part of C to avoid is raw pointers and malloc, and generally anything where C++ has a more modern alternative. Don't use C datastructures (pointers, strings, arrays) where C++ replacements exist (smart pointers, std:string, std::array and std::vector, etc), or use C libraries where C++ replacements exist (e.g. C++ std::string vs C's string.h).

Of course you can't avoid all of C, since the syntax of C++ is an extension of C.

2) I wouldn't characterize what C++ adds to C as OOP. OOP is a design methodology, whereas the main addition C++ gives you is classes which are better thought of just as powerful and convenient type of data structure.

The core feature of classes you always want to use are constructors and destructors. Any initialization of the class's data members should be done in the constructor (don't leave things uninitialized), and any final cleanup (releasing memory or locks, closing files, etc) should be put in the destructor so that it always happens (even if your program throws exceptions).

Don't feel that just because classes support subclassing, polymorphism (virtual methods), etc, that you should be using them. They are there in case you need them, but if in doubt don't.

3a) The STL is just the standard library for C++. You should always be using STL data structures (std::string, std::list, std::vector, std::map, etc) when applicable - not just "for productivity".

3b) Templates (template classes, constructors/methods, functions) are not needed for most everyday use of C++. They are there for library writers, and on occasion for writing your own class and libraries. Think of them a bit like class inheritence - they are there in case you need them, but not something you should be reaching for unless there is no better way.

4) C++ has a LOT of stuff (esp. libraries) that might be considered as "for special case use only". A rookie mistake might be to think that C++ has all this stuff - I should be using it! In general you should ignore the obscure stuff, and only use it when some special circumstance requires it.