These can be expressed in a slightly cleaner manner without so many
casts. While we're at it, also get rid of unnecessary indexing (we
already have the result nearby).
Gets rid of a second pair of ifdefs in the constructor. This also makes
sure the fd on Unix/BSD platforms is uniformly initialized. Previously
fd would be in an inconsistent state on FreeBSD or OpenBSD due to the
BSD OS checks not being present in the #elif within the constructor.
Previously, the entirety of CEXIETHERNET was exposed publically, which
wasn't necessary. We simply make the thread function part of the
internal interface, which gives it access to internal data members,
while keeping everything else outside of it.
Given these HLE classes inherit from a common base with a virtual
destructor, override is more appropriate here, as virtual propagates to
these destructors anyway.
This is also safer. If the base class' destructor is ever made
non-virtual, then these classes will cause a compilation error if they
aren't taken into account, as they'd be overriding a non-virtual
function (the destructor).
Paired single (ps) instructions can call asm_routines that try to update
PowerPC::ppcState.pc. At the time the asm_routine is built, emulation has
not started and the PC is invalid (0). If the ps instruction causes an
exception (e.g. DSI), SRR0 gets clobbered with the invalid PC.
This change makes the relevant ps instructions store PC before calling out
to asm_routines, and prevents the asm_routine from trying to store PC
itself.
Moves the codebuffer access variables closer to their first use, and
gets rid of multiple indexing expressions. We already know which op
we're accessing in particular, so just make a reference to it and access
it instead of duplicating the expression all over the place.
Makes the enum strongly typed. A function for retrieving the string
representation of the enum is also added, which allows hiding the array
that contains all of the strings from view (i.e. we operate on the API,
not the exposed internals). This also allows us to bounds check any
querying for the strings.
Export and ExportAll now open a directory picker (that defaults to the
previous default directory, i.e. the Dolphin user dir).
Also removes the need to return the path in the export functions since
the user knows which path they chose.
This moves the result dialogs to DolphinQt2, since WiiSave should not
really be responsible for interacting with the user as a simple
Wii save importing/exporting class.
This also fixes Wii save import/export showing result dialogs twice,
once from WiiSave, and another time from DolphinQt2.
Move the import/export operation into separate functions, as it doesn't
really make sense for the constructor to do *everything*, including
printing success/failure message boxes.
The existing constructor was split into two: one that takes a path,
and another taking a title ID. This makes it more obvious what is
actually done when a path/TID is passed and also clarifies what
parameters should be passed. (No more magic 0 or "" value.)
This allows avoiding two copies of the executable data being created in
the following scenario (using pseudocode):
some_function()
{
std::vector<u8> data = ...;
DolReader reader{data};
...
}
In this scenario, if we only use the data for passing it to DolReader,
then we have to perform a copy, as the constructor takes the std::vector
as a constant reference -- you cannot move from a constant reference,
and so we copy data into the DolReader, and perform another copy in the
constructor itself when assigning the data to the m_bytes member
variable. However, we can do better.
Now, the following is allowable as well:
some_function()
{
std::vector<u8> data = ...;
DolReader reader{std::move(data)};
...
}
and now we perform no copy at any point in the reader's construction, as
we just std::move the data all the way through to m_bytes.
In the case where we *do* want to keep the executable data around after
constructing the reader, then we can just pass the vector without
std::move-ing it, and we only perform a copy once (as we'll std::move
said copy into m_bytes). Therefore, we get a more flexible interface
resource-wise out of it.
This makes it possible to use enums as the config type.
Default values are now clearer and there's no need for casts
when calling Config::Get/Set anymore.
In order to add support for enums, the common code was updated to
handle enums by using the underlying type when loading/saving settings.
A copy constructor is also provided for conversions from
`ConfigInfo<Enum>` to `ConfigInfo<underlying_type<Enum>>`
so that enum settings can still easily work with code that doesn't care
about the actual enum values (like Graphics{Choice,Radio} in DolphinQt2
which only treat the setting as an integer).
