Also move it to MathUtils where it belongs with the rest of the
power-of-two functions. This gets rid of pollution of the current scope
of any translation unit with b<value> macros that aren't intended to be
used directly.
Change SettingsHandler to take a buffer instead of assuming that the
setting file to read is always on the host filesystem for more
flexibility and make it possible to use the new filesystem interface.
Given bit conversions between types are quite common in emulation
(particularly when it comes to floating-point among other things) it
makes sense to provide a utility function that keeps all the boilerplate
contained; especially considering it makes it harder to accidentally
misuse std::memcpy (such as accidentally transposing arguments, etc).
Another benefit of this function is that it doesn't require separating
declarations from assignments, allowing variables to be declared const.
This makes the scenario of of uninitialized variables being used less
likely to occur.
As of VS 15.7, these seem to have been removed. Given we shouldn't have
been using these for some time, just replace them with the standard
library equivalent.
This fixes building on Windows with VS 15.7
Keeps all of the floating-point utility functions in their own file to
keep them all together. This also provides a place for other
general-purpose floating-point functions to be added in the future,
which will be necessary when improving the flag-setting within the
interpreter.
Since all FS access will go through the new FS interface (PR #6421)
in order to keep track of metadata properly, there is no need to return
absolute paths anymore.
In fact, returning host paths is a roadblock to using the FS interface.
This starts the migration work by adding a way to get paths that are
relative to the Wii NAND instead of always getting absolute paths
on the host FS.
To prepare for future changes, this commit also makes returned paths
canonical by removing the trailing slash when it's unneeded.
Eventually, once everything has been migrated to the new interface,
we can remove the "from" parameter.
Allows us to bring includes and relevant libraries into scope by explicitly declaring linkage against the target
as opposed to using a variable. Also removes the dumping of OProfile includes into the top-level directory.
There's no real requirement to make this const, and this should also
be decided by the calling code, considering we had places that would
simply cast away the const and carry on.
