We (the Microsoft C++ team) use the dolphin project as part of our "Real world code" tests.
I noticed a few issues in windows specific code when building dolphin with the MSVC compiler
in its conformance mode (/permissive-). For more information on /permissive- see our blog
https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/.
These changes are to address 3 different types of issues:
1) Use of qualified names in member declarations
struct A {
void A::f() { } // error C4596: illegal qualified name in member declaration
// remove redundant 'A::' to fix
};
2) Binding a non-const reference to a temporary
struct S{};
// If arg is in 'in' parameter, then it should be made const.
void func(S& arg){}
int main() {
//error C2664: 'void func(S &)': cannot convert argument 1 from 'S' to 'S &'
//note: A non-const reference may only be bound to an lvalue
func( S() );
//Work around this by creating a local, and using it to call the function
S s;
func( s );
}
3) Add missing #include <intrin.h>
Because of the workaround you are using in the code you will need to include
this. This is because of changes in the libraries and not /permissive-
ControllerEmu, the class, is essentially acting like a namespace for
ControlGroup. This makes it impossible to forward declare any of the
internals. It also globs a bunch of classes together which is kind of a
pain to manage.
This splits ControlGroup and the classes it contains into their own source
files and situates them all within a namespace, which gets them out of
global scope.
Since this allows forward declarations for the once-internal classes, it
now requires significantly less files to be rebuilt if anything is changed
in the ControllerEmu portion of code.
It does not split out the settings classes yet, however, as it
would be preferable to make a settings base class that all settings derive
from, but this would be a functional change -- this commit only intends to
move around existing code. Extracting the settings class will be done in
another commit.
Several of the things done while performing a scan are logically their own
behavior (e.g. loading a titles file, checking if an entry should be added, etc).
It held a raw pointer to a IOS::HLE::Device::BluetoothEmu that is not
guaranteed to exist (and of course, nothing checked that it wasn't
nullptr), but what is more, it's totally unnecessary because we have
IOS::HLE::GetDeviceByName().
Since we cannot always inform the host that Wii remotes are
disconnected from ES, that is now done in BluetoothEmu's destructor.
Better separation of concerns. Relegates `ControllerInterface` to
enumerating input controls, and the new `ControlReference` deals with
combining inputs and configuration expression parsing.
ControllerEmu is a massive class with a lot of nested public classes.
The only reason these are nested is because the outer class acts as a
namespace. There's no reason to keep these classes nested just for that.
Keeping these classes nested makes it impossible to forward declare them, which leads to quite a few includes in other headers, making compilation take
longer.
This moves the source files to their own directory so classes can be
separated as necessary to their own source files, and be namespaced under the
ControllerEmu namespace.
Any functions left exposed are used elsewhere through the main_window
global. May as well prevent any more functions from being used in that
manner where possible.
Utilizes the event system (which is what should have been done here
initially), in order to prevent coupling between two different window frames.
This also makes booting games more versatile using the UI event system,
as the event can just act as a carrier for the filename, making directly
calling boot functions unnecessary. All that's needed is for the event to
propagate to the frame.
Since files from Data/Sys are collected and added to a built macOS .app
bundle using GLOB, any new files won't get picked up until the next time
CMake is run. Tell CMake it should re-run itself every time the directory
is touched.
Instead of using install() commands, we use the MACOSX_PACKAGE_LOCATION
property, which will allow the files to be identified and updated individually
by the build system without having to remove the entire folder and copy it
each time.
deploy-mac.py is now idempotent and should be working properly, so we'll
call it all the time from now on.
Phil Christensen