* get rid of boost::optional
* Remove optional references
* Use std::reference_wrapper for optional references
* Fix clang format
* Fix clang format part 2
* Adressed feedback
* Fix clang format and MacOS build
* Fixed conflict with nfp
* Few fixups for nfc
* Conflict 2
* Fixed AttachAvailabilityChangeEvent
* Conflict 3
* Fixed byte padding
* Refactored amiibo to not reside in "System"
* Removed remaining references of nfc from system
* used enum for Nfc GetStateOld
* Added missing newline
* Moved file operations to front end
* Conflict 4
* Amiibos now use structs and added mutexes
* Removed amiibo_path
Neither of these functions alter the ownership of the provided pointer,
so we can simply make the parameters a reference rather than a direct
shared pointer alias. This way we also disallow passing incorrect memory values like
nullptr.
We can utilize QStringList's join() function to perform all of the
appending in a single function call.
While we're at it, make the extension list a single translatable string
and add a disambiguation comment to explain to translators what %1
actually is.
Depending on whether or not USE_DISCORD_PRESENCE is defined, the "state"
parameter can be used or unused. If USE_DISCORD_PRESENCE is not defined,
the parameter will be considered unused, which can lead to compiler
warnings. So, we can explicitly mark it with [[maybe_unused]] to inform
the compiler that this is intentional.
Makes the public interface consistent in terms of how accesses are done
on a process object. It also makes it slightly nicer to reason about the
logic of the process class, as we don't want to expose everything to
external code.
Ternary operators have a lower precedence than arithmetic operators, so
what was actually occurring here is "return (out + full) ? x : y" which most
definitely isn't intended, given we calculate out recursively above. We
were essentially doing a lot of work for nothing.
This can cause warnings about static constructors, and is also not ideal
performance-wise due to the indirection through std::function. This also
keeps the behavior itself separate from the surrounding code, which can
make it nicer to read, due to the size of the code.
It allows us to use texture views and it reduces the overhead within the GPU driver.
But it disallows us to reallocate the texture, but we don't do so anyways.
In the end, it is the new way to allocate textures, so there is no need to use the old way.
Lets us keep the generic portions of the compatibility list code
together, and allows us to introduce a type alias that makes it so we
don't need to type out a very long type declaration anymore, making the
immediate readability of some code better.
Dharmin K Shah