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.
There were a few places where nested namespace specifiers weren't being
used where they could be within the service code. This amends that to
make the namespacing a tiny bit more compact.
This was very likely intended to be a logical OR based off the
conditioning and testing of inversion in one case.
Even if this was intentional, this is the kind of non-obvious thing one
should be clarifying with a comment.
Multi-line doc comments still need the '<' after the ///, otherwise it's
treated as a regular comment and makes the original doc comment broken
in viewers, IDEs, etc. While we're at it, also fix some typos in the
comments.
While likely very uncommon, this sanitizes the input and does nothing in
the event of the length being equal to or less than zero, avoiding
constructing a std::string when there's no need to. It also avoids an
out-of-memory scenario, as a negative value would wrap around to its
equivalent unsigned representation in std::string's constructor.
e.g. If someone was silly and a length of -1 was specified, this would
make a string with a length of 0xFFFFFFFFFFFFFFFF on a 64-bit platform,
which will obviously eventually fail due to the allocation being way too
large.
"value" is already a used variable name within the outermost ranged-for
loop, so this variable was shadowing the outer one. This isn't a bug,
but it will get rid of a -Wshadow warning.
These currently aren't used and contain commented out source code that
corresponds to Dolphin's JIT. Given our CPU code is organized quite
differently, we shouldn't be keeping this around (at the moment it just
adds to compile times marginally).
Given these functions aren't intended to be used frequently, there's no
need to keep the std::string instances allocated for the whole lifetime
of the program. It's just a waste of memory.
Despite being covered by a global mutex, we should still ensure that the
class handles its reference counts properly. This avoids potential
shenanigans when it comes to data races.
Given this is the root object that drives quite a bit of the kernel
object hierarchy, ensuring we always have the correct behavior (and no
races) is a good thing.
The filter is returned via const reference, so this was making a
pointless copy of the entire filter every time a message was being
pushed into the logger instance.
Rather than having to type out the full std::map type signature, we can
just use a straightforward alias. While we're at it, rename
GetBreakpointList to GetBreakpointMap, which makes the name more
accurate. We can also get rid of unnecessary u64 static_casts, since
VAddr is an alias for a u64.
Instead, we make a proper registry class and house it within the main
window, then pass it to whatever needs access to the loaded hotkeys.
This way, we avoid a global variable, and don't need to initialize a
std::map instance before the program can do anything.
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.
Using member variables for referencing the segments array increases the
size of the class in memory for little benefit. The same behavior can be
achieved through the use of accessors that just return the relevant
segment.
General moving to keep kernel object types separate from the direct
kernel code. Also essentially a preliminary cleanup before eliminating
global kernel state in the kernel code.
Avoids using a u32 to compare against a range of size_t, which can be a
source of warnings. While we're at it, compress a std::tie into a
structured binding.
Gets rid of the need to hardcode the type in multiple places. This will
now be deduced automatically, based off the elements in the container
being provided to the algorithm.
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
There's no need to perform the resize separately here, since the
constructor allows presizing the buffer.
Also move the empty string check before the construction of the string
to make the early out more straightforward.
This is equivalent to doing:
push_back(std::string(""));
which is likely not to cause issues, assuming a decent std::string
implementation with small-string optimizations implemented in its
design, however it's still a little unnecessary to copy that buffer
regardless. Instead, we can use emplace_back() to directly construct the
empty string within the std::vector instance, eliminating any possible
overhead from the copy.
We can just use the variant of std::string's replace() function that can
replace an occurrence with N copies of the same character, eliminating
the need to allocate a std::string containing a buffer of spaces.
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.
We can just leverage std::unique_ptr to automatically close these for us
in error cases instead of jumping to the end of the function to call
fclose on them.
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).
This doesn't depend on class state at all, so this can be made internal.
While we're at it, amend the function to take its arguments by const reference.
QString initializes to an empty string by default, so this does nothing
meaningful. While we're at it, use a constructor initializer list for
initializing the gamelist member variable.
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.
