The vector is only ever queryied and it's contents aren't modified, so
there's no reason to take the vector by value. We can take a constant
reference to it to avoid unnecessary allocating.
In these cases, the given string is only ever compared against other
string, so std::string can be turned into a std::string_view to allow
non-allocating inputs.
The CMakeLists file for the static zlib checks for presence of
unistd.h, but it doesn't properly define HAVE_UNISTD_H if it's found.
This change adds the necessary preprocessor definition if unistd.h is
found.
Upstream zlib handles this with by configuring zconf.h with CMake:
cacf7f1d4e/zconf.h.cmakein (L11)
Dolphin's static version of zlib doesn't do this, which is why setting
Z_HAVE_UNISTD_H in zlib's CMakeLists.txt isn't enough.
This probably wasn't noticed since because most *nix systems will use
the shared zlib. Force use of the static zlib (comment out
find_package(ZLIB) in the root CMakeLists.txt) and you'll see implicit
function declaration warnings during its compilation.
Ensures that the destruction logic is kept local to the translation unit
(making it nicer when it comes to forward declaring non-trivial types).
It also doesn't really do much to define it in the header.
Given we're simply storing the std::string into a deque. We can emplace
it and move it. Completely avoiding copies with the current usage of the
function.
The pack is already has its validity checked at the beginning of the
function, so we don't need to check this again after inserting it.
Also resolves a use-after-move case.
Same behavior but doesn't take up 8 bytes in the executable to store a
pointer. While we're at it, move it into an anonymous namespace within
the UICommon namespace.
We already check ahead of time if the optional contains a value within
it before accessing it, so we don't need to use the throwing value()
accessor. We can just directly use operator->
Rather than construct strings twice, we can just construct it once and
reuse it. While we're at it, we can move variables closer to where
they're actually used within DownloadDefaultCover()
* Simplifies libusb context usage and allows us to set options for
all contexts easily. Notably, this lets us enable usbdk support
in libusb, which is now opt-in in the latest version.
* Moves the libusb config descriptor wrapper class to LibusbUtils too
since that could easily be reused.
* Moves device listing to LibusbUtils too and add a lock around it
as some libusb backends are not thread safe.
* Consequences: only a single context and a single event handling
thread is used now, which is more efficient.
In some cases, this is required to avoid eventually getting a
USBD_STATUS_BAD_START_FRAME error back from the Windows USB stack.
This makes the libusbK code match the behaviour of the Linux backend.
It appears that the libusbK backend tried to get this behaviour by
setting StartFrame to 0. However, libusbK docs state that:
"Specifing 0 for KISO_CONTEXT::StartFrame (start transfer ASAP) is
restricted to the first transaction on a newly opened or reset pipe."
This allows the same code to be used to read into a std::string, which
allows for eliminating the vector->string transfer when reading the
manifest file.
A ContiguousContainer is a concept that includes std::array,
std::string, and std::vector.
Makes it way harder to introduce resource leaks, and plugs the existing
resource leaks in the constructor and Install() where the file wouldn't
be closed in some error cases.
Now that we assume C++17, the in-file definition of the std::array can
be removed. This is all that's necessary, as constexpr used on a static
member variable implies inline (and so, automatically has C++17's static
inline behavior).
Lioncash