We can avoid constructing a std::vector here by simply passing a pointer
to the original data and the size of the copy we wish to perform to the
backend's Write() function instead, avoiding copying the data where it's
otherwise not needed.
We were using a second std::vector as a buffer to convert another
std::vector's data into a byte sequence, however we can just use
pointers to the original data and use them directly with WriteBuffer,
which avoids copying the data at all into a separate std::vector.
We simply cast the pointers to u8* (which is allowed by the standard,
given std::uint8_t is an alias for unsigned char on platforms that we
support).
Previously we were just copying the data whole-sale, even if the length
was less than the total data size. This effectively makes the
actual_data vector useless, which is likely not intended.
Instead, amend this to only copy the given length amount of data.
At the same time, we can avoid zeroing out the data before using it by
passing iterators to the constructor instead of a size.
These are unused and essentially don't provide much benefit either. If
we ever need rotation functions, these can be introduced in a way that
they don't sit in a common_* header and require a bunch of ifdefing to
simply be available
Android and macOS have supported thread_local for quite a while, but
most importantly is that we don't even really need it. Instead of using
a thread-local buffer, we can just return a non-static buffer as a
std::string, avoiding the need for that quality entirely.
Previously is_hfs and pfs_header members wouldn't be initialized in the
constructor, as they were stored in locals instead. This would result in
things like GetName() and PrintDebugInfo() behaving incorrectly.
While we're at it, initialize the members to deterministic values as
well, in case loading ever fails.
This was introduced within 4f81bc4e1bd12e4df7410c6790ba818d8dbba9c0, and
considering there's no comment indicating that this is intentional, this
is very likely a bug.
This makes it a compilation error to construct additional instances of
the System class directly, preventing accidental wasteful constructions
over and over.
This would result in a lot of allocations and related object
construction, just to toss it all away immediately after the call.
These are definitely not intentional, and it was intended that all of
these should have been accessing the static function GetInstance()
through the name itself, not constructed instances.
