[ashleighz]

I don't necessarily agree. Using shared_ptr to not worry about lifetimes, a la C#, is not inherently a bad thing, not all code has to pretend to be Rust, especially a hobby project. From what I see, they're only really being used as dependency injection. So it has the benefits of the garbage collected model with none of the downsides

Also, speaking as a C++ game developer by profession, taking a shared_ptr copy and moving from it is a common way of saying "I will take a copy of this and keep it alive" whereas a shared_ptr ref only communicates that it can or might

[jpc0]

RAII using a unique_ptr in this case would have the benefits of a GC without any of the performance loss of an atomic or a lock depending on implementation.

Regarding "I will take a copy and ... keep it alive..." That is literally what the copy constructor of a sharedpointer does, you wouldn't need a move for that, the move literally just prevents the atomic increment.

I'm not saying there isn't a use case for shared_ptr, just that in this codebase at least in parts of it you could string replace with unique_ptr and get a free performance boost ( as trivial as it would be if the compiler hasn't already just done that ) because the atomic ref count is not needed.

OP did however clarify some design decisions on why the shared_ptr in some parts of the code and that is fine.

I stick by my statement. Stop using std::shared_ptr. Use std::unique_ptr and then convert to shared when it is actually necessary.

My point in C# was a mean spirited dig, but really though, you are giving up a ton of library features from C# by coding in C++ to then just treat it like C#. Write it in C# using the library that has already been optimised...