Allows avoiding unnecessary copies of the vector depending on the
calling code.
While we're at it, remove a redundant no-parameter base constructor call
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.
Allows pushing strongly-typed enum members without the need to always
cast them at the call sites.
Note that we *only* allow strongly-typed enums in this case. The reason
for this is that strongly typed enums have a guaranteed defined size, so
the size of the data being pushed is always deterministic. With regular
enums this can be a little more error-prone, so we disallow them.
This function simply uses the underlying type of the enum to determine
the size of the data. For example, if an enum is defined as:
enum class SomeEnum : u16 {
SomeEntry
};
if PushEnum(SomeEnum::SomeEntry); is called, then it will push a
u16-size amount of data.
And make IManagerForApplication::CheckAvailability always return false.
Returning a bogus id from GetAccountId causes games to crash on boot.
We should investigate this with a hwtest and either stub it properly or implement it.
Uses a type that doesn't potentially dynamically allocate, and ensures
that the name of the interface is properly null-terminated when writing
it to the buffer.
The default username for now is "yuzu".
We should eventually allow the creation of users in the emulator and have the ability to modify their parameters.
This introduces a slightly more generic variant of WriteBuffer().
Notably, this variant doesn't constrain the arguments to only accepting
std::vector instances. It accepts whatever adheres to the
ContiguousContainer concept in the C++ standard library.
This essentially means, std::array, std::string, and std::vector can be
used directly with this interface. The interface no longer forces you to
solely use containers that dynamically allocate.
To ensure our overloads play nice with one another, we only enable the
container-based WriteBuffer if the argument is not a pointer, otherwise
we fall back to the pointer-based one.
The reason this would never be true is that ideal_processor is a u8 and
THREADPROCESSORID_DEFAULT is an s32. In this case, it boils down to how
arithmetic conversions are performed before performing the comparison.
If an unsigned value has a lesser conversion rank (aka smaller size)
than the signed type being compared, then the unsigned value is promoted
to the signed value (i.e. u8 -> s32 happens before the comparison). No
sign-extension occurs here either.
An alternative phrasing:
Say we have a variable named core and it's given a value of -2.
u8 core = -2;
This becomes 254 due to the lack of sign. During integral promotion to
the signed type, this still remains as 254, and therefore the condition
will always be true, because no matter what value the u8 is given it
will never be -2 in terms of 32 bits.
Now, if one type was a s32 and one was a u32, this would be entirely
different, since they have the same bit width (and the signed type would
be converted to unsigned instead of the other way around) but would
still have its representation preserved in terms of bits, allowing the
comparison to be false in some cases, as opposed to being true all the
time.
---
We also get rid of two signed/unsigned comparison warnings while we're
at it.
We can use emplace_back to construct the Display instances directly,
instead of constructing them separately and copying them, avoiding the
need to copy std::string and std::vector instances that are part of the
Display struct.
Previously, the buffer_index parameter was unused, causing all writes to
use the buffer index of zero, which is not necessarily what is wanted
all the time.
Thankfully, all current usages don't use a buffer index other than zero,
so this just prevents a bug before it has a chance to spring.
Lioncash