Like the prior changes normalizing the inclusions within headers, this
tackles the cpp files of the RuntimeCommonB target, making these source
files consistent with their headers.
Makes the arrays strongly typed and impervious to array->pointer decay.
This also allows simplifying some operations (such as being able to call
fill() instead of needing to use std::fill, etc).
Now, with all of the headers normalized, we can safely convert some
headers into forward declarations without needing to worry about
potentially breaking code in other headers or source files.
Includes all necessary headers and uses a forward declaration where
applicable. Ensures inclusion changes in other headers don't break the compilation
of these headers and source files.
Makes the arrays strongly-typed and impervious to implicit
array->pointer decay.
This also uncovered an out of bounds memory read within UpdateEffects
cause by said array->pointer decay.
The strcasecmp and _stricmp functions expect the passed in strings to
be null-terminated, however we we're also exposing a std::string_view
overload for that function. std::string_view instances aren't required
to be null-terminated, so this makes the interface a little unsafe.
We can use std::lexicographical_compare() to provide the same behavior
and also properly handle the case of non-null-terminated strings.
Makes use of the C++14 make_unique allocation function to allocate class
instances where applicable instead of a reset with a new operator within
it.
This doesn't touch cases where buffers are allocated, given make_unique
would zero-initialize them.
Technically this array wasn't readonly and contained a sequence of
modifiable elements. We can make this constexpr so that the compiler can
definitively place it into the read-only segment.
We can just use the result of the find operation instead of rehashing
into the map to retrieve the entry.
This also allows us to make the getter const qualified.
This is incremented within PathFind(), however, because the type within
this bitfield is a bool, this can trigger compilation warnings (rightly
so). So we can make it a uint32_t to make it obvious that the
incrementing behavior is intended.