Previously the constructor for all of these would run at program
startup, consuming time before the application can enter main().
This is also particularly dangerous, given the logging system wouldn't
have been initialized properly yet, yet the program would use the logs
to signify an error.
To rectify this, we can replace the literals with constexpr functions
that perform the conversion at compile-time, completely eliminating the
runtime cost of initializing these arrays.
In a few places, the data to be set as the IV is already within an array.
We shouldn't require this data to be heap-allocated if it doesn't need
to be. This allows certain callers to reduce heap churn.
Previously, we were reading the keys everytime a KeyManager object was created, causing yuzu to reread the keys file multiple hundreds of times when loading the game list.
With this change, it is only loaded once.
On my system, this decreased game list loading times by a factor of 20.
This properly handles unicode-based paths on Windows, while opening a
raw stream doesn't out-of-the-box.
Prevents file creation from potentially failing on Windows PCs that make
use of unicode characters in their save paths (e.g. writing to a user's
AppData folder, where the user has a name with non-ASCII characters).
Since the introduction of this library, numerous improvements have been
made. Notably, many of the warnings we would get by simply including the
library header have now been fixed. This makes it much easier to make
conversion warning an error.
These can be generified together by using a concept type to designate
them. This also has the benefit of not making copies of potentially very
large arrays.
* Fixes Unicode Key File Directories
Adds code so that when loading a file it converts to UTF16 first, to
ensure the files can be opened. Code borrowed from FileUtil::Exists.
* Update src/core/crypto/key_manager.cpp
Co-Authored-By: Jungorend <Jungorend@users.noreply.github.com>
* Update src/core/crypto/key_manager.cpp
Co-Authored-By: Jungorend <Jungorend@users.noreply.github.com>
* Using FileUtil instead to be cleaner.
* Update src/core/crypto/key_manager.cpp
Co-Authored-By: Jungorend <Jungorend@users.noreply.github.com>
We can just return a new instance of this when it's requested. This only
ever holds pointers to the existing registed caches, so it's not a large
object. Plus, this also gets rid of the need to keep around a separate
member function just to properly clear out the union.
Gets rid of one of five globals in the filesystem code.
* 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
We can just reserve the memory then perform successive insertions
instead of needing to use memcpy. This also avoids the need to zero out
the output vector's memory before performing the insertions.
We can also std::move the output std::vector into the destination so
that we don't need to make a completely new copy of the vector, getting
rid of an unnecessary allocation.
Additionally, we can use iterators to determine the beginning and end
ranges of the std::vector instances that comprise the output vector, as
the end of one range just becomes the beginning for the next successive
range, and since std::vector's iterator constructor copies data within
the range [begin, end), this is more straightforward and gets rid of the
need to have an offset variable that keeps getting incremented to
determine where to do the next std::memcpy.
Given it's only used in one spot and has a fairly generic name, we can
just specify it directly in the function call. This also the benefit of
automatically moving it.
Instead, we can make it part of the type and make named variables for
them, so they only require one definition (and if they ever change for
whatever reason, they only need to be changed in one spot).
Given the VirtualFile instance isn't stored into the class as a data
member, or written to, this can just be turned into a const reference,
as the constructor doesn't need to make a copy of it.
If the data is unconditionally being appended to the back of a
std::vector, we can just directly insert it there without the need to
insert all of the elements one-by-one with a std::back_inserter.
