Instead of using an unsigned int as a parameter and expecting a user to
always pass in the correct values, we can just convert the enum into an
enum class and use that type as the parameter type instead, which makes
the interface more type safe.
We also get rid of the bookkeeping "NUM_" element in the enum by just
using an unordered map. This function is generally low-frequency in
terms of calls (and I'd hope so, considering otherwise would mean we're
slamming the disk with IO all the time) so I'd consider this acceptable
in this case.
This avoids a redundant std::string construction if a key doesn't exist
in the map already.
e.g.
data[key] requires constructing a new default instance of the value in
the map (but this is wasteful, since we're already setting something
into the map over top of it).
Allows avoiding constructing std::string instances, since this only
reads an arbitrary sequence of characters.
We can also make ParseFilterRule() internal, since it doesn't depend on
any private instance state of Filter
These can just use a view to a string since its only comparing against
two names in both cases for matches. This avoids constructing
std::string instances where they aren't necessary.
These are unused and essentially don't provide much benefit either. If
we ever need rotation functions, these can be introduced in a way that
they don't sit in a common_* header and require a bunch of ifdefing to
simply be available
Android and macOS have supported thread_local for quite a while, but
most importantly is that we don't even really need it. Instead of using
a thread-local buffer, we can just return a non-static buffer as a
std::string, avoiding the need for that quality entirely.
These operators don't modify internal class state, so they can be made
const member functions. While we're at it, drop the unnecessary inline
keywords. Member functions that are defined in the class declaration are
already inline by default.
This provides the equivalent behavior, but without as much boilerplate.
While we're at it, explicitly default the move constructor, since we
have a move-assignment operator defined.
* More improvements to GDBStub
- Debugging of threads should work correctly with source and assembly level stepping and modifying registers and memory, meaning threads and callstacks are fully clickable in VS.
- List of modules is available to the client, with assumption that .nro and .nso are backed up by an .elf with symbols, while deconstructed ROMs keep N names.
- Initial support for floating point registers.
* Tidy up as requested in PR feedback
* Tidy up as requested in PR feedback
* Add VfsFile and VfsDirectory classes
* Finish abstract Vfs classes
* Implement RealVfsFile (computer fs backend)
* Finish RealVfsFile and RealVfsDirectory
* Finished OffsetVfsFile
* More changes
* Fix import paths
* Major refactor
* Remove double const
* Use experimental/filesystem or filesystem depending on compiler
* Port partition_filesystem
* More changes
* More Overhaul
* FSP_SRV fixes
* Fixes and testing
* Try to get filesystem to compile
* Filesystem on linux
* Remove std::filesystem and document/test
* Compile fixes
* Missing include
* Bug fixes
* Fixes
* Rename v_file and v_dir
* clang-format fix
* Rename NGLOG_* to LOG_*
* Most review changes
* Fix TODO
* Guess 'main' to be Directory by filename
Without this, it's possible to get compilation failures in the (rare) scenario where
a container is used to store a bunch of live IOFile instances, as they may be using
std::move_if_noexcept under the hood. Given these definitely don't throw exceptions
this is also not incorrect to add either.
Ensure that the actual types being passed in are trivially copyable. The internal
call to ReadArray() and WriteArray() will always succeed, since they're passed a pointer to char*
which is always trivially copyable.
The minimum clang/GCC versions we support already support this. We can also
remove is_standard_layout(), as fread and fwrite only require the type to be
trivially copyable.
These are all unused and the Write() ones should arguably not even be in the interface. There are better ways to provide this if we ever need it (like iterators).
Additionally, when updating fmtlib, there was a change in fmtlib broke
how the old logging macro was overloaded, so this works around that by
just naming the fmtlib macro impl something different
swap{16,32,64} are defined as macros on the two, but client code
tries to invoke them as Common::swap{16,32,64}, which naturally
doesn't work. This hack redefines the macros as inline functions
in the Common namespace: the bodies of the functions are the
same as the original macros, but relying on OS-specific
implementation details like this is of course brittle.
Add a new set of logging macros based on fmtlib
Similar but not exactly the same as https://github.com/citra-emu/citra/pull/3533
Citra currently uses a different version of fmt, which does not support FMT_VARIADIC so
make_args is used instead. On the other hand, yuzu uses fmt 4.1.0 which doesn't have make_args yet
so FMT_VARIADIC is used.
