Adds an interface that uses fmt under the hood, which is much more
flexible than printf, particularly for localization purposes, given fmt
supports positional formatters in a cross-platform manner out of the box
with no configuration necessary.
Noticed missing include as a build failure on gcc-11:
```
[ 15%] Building CXX object Source/Core/Common/CMakeFiles/common.dir/Config/Config.cpp.o
Source/Core/Common/Config/Config.cpp:23:24:
error: 'unique_lock' in namespace 'std' does not name a template type
23 | using WriteLock = std::unique_lock<std::shared_mutex>;
| ^~~~~~~~~~~
Source/Core/Common/Config/Config.cpp:11:1:
note: 'std::unique_lock' is defined in header '<mutex>';
did you forget to '#include <mutex>'?
```
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Much of these classes are operating on integral types and are pretty
standard behavior as far as vectors go. Some member functions can be
made constexpr to make them more flexible and allow them to be used in
constexpr contexts.
Provides a basic extension to the interface to begin migration off of
the printf-based logging system.
Everything will go through macros with the same style naming as the old
logging system, except the macros will have the _FMT suffix, while the
migration is in process.
This allows for peacemeal migration over time instead of pulling
everything out and replacing it all in a single pull request, which
makes for much easier reviewing.
Common shouldn't be depending on APIs in Core (in this, case depending
on the PowerPC namespace). Because of the poor separation here, this
moves OSThread functionality into core, so that it resolves the implicit
dependency on core.
CommandLineParse expects UTF-8 strings. (QApplication, on the
other hand, seems to be designed so that you can pass in the
char** argv untouched on Windows and get proper Unicode handling.)
Fixes a critical regression where 95945a0 made us unable to
start emulation on Android 10 and newer. Android is restricting
direct access to /dev/ashmem starting with the new SDK version,
but we can use the new (and simpler) ASharedMemory API instead.
We have to keep using the /dev/ashmem approach on old versions
of Android, though.
The functions with "UTF" in the name use "modified UTF-8" rather
than the standard UTF-8 which Dolphin uses, at least according
to Oracle's documentation, so it is incorrect for us to use them.
This change fixes the problem by converting between UTF-8 and
UTF-16 manually instead of letting JNI do it for us.
This function does *not* always convert from UTF-16. It converts
from UTF-16 on Windows and UTF-32 on other operating systems.
Also renaming UTF8ToUTF16 for consistency, even though it
technically doesn't have the same problem since it only was
implemented on Windows.
Also added a IsRunning function as it was impossible to know whether it had been started or not (I will use it in later PRs but it should be there anyway)
`std::abs(x - y)` where x and y are unsigned integers fails to compile
with an "call of overloaded 'abs(unsigned int)' is ambiguous" error
on GCC, and even if it did compile, that expression still wouldn't
give the correct result since `x - y` is unsigned.
Without included header build fails on gcc-10 as:
```
[ 13%] Building CXX object Source/Core/AudioCommon/CMakeFiles/audiocommon.dir/CubebUtils.cpp.o
In file included from ../../../../Source/Core/AudioCommon/CubebUtils.cpp:13:
../../../../Source/Core/Common/StringUtil.h: In function 'bool TryParse(const string&, T*)':
../../../../Source/Core/Common/StringUtil.h:84:20: error: 'numeric_limits' is not a member of 'std'
84 | if (value < std::numeric_limits<LimitsType>::min() ||
| ^~~~~~~~~~~~~~
```
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
So far in all our uses of ScopeGuard, the type of the callable is
usually just a lambda or a function pointer, so there is no need
to rely on std::function's type erasure.
While the cost of using std::function is probably negligible, it still
causes some unnecessary overhead that can be avoided by making
ScopeGuard a templated class. Thanks to class template argument
deduction in C++17 most existing usages do not even need to be changed.
See https://godbolt.org/z/KcoPni for a comparison between
a ScopeGuard that uses std::function and one that doesn't
Add a function that safely returns whether a character is printable
i.e. whether 0x20 <= c <= 0x7e is true.
This is done in several places in our codebase and it's easy to run
into undefined behaviour if the C version defined in <cctype>
is used instead of this one, since its behaviour is undefined
if the character is not representable as an unsigned char.
This fixes MemoryViewWidget.
Due to the way the ModRM encoding works on x86, memory addressing
combinations involving RBP or R13 need an additional byte for an 8-bit
displacement of zero.
However, this was also applied in cases where it is unnecessary,
effectively wasting a byte.
- MatR with RSP or R12
8B 44 24 00 mov eax,dword ptr [rsp]
8B 04 24 mov eax,dword ptr [rsp]
- MRegSum with base != RBP or R13
46 8D 7C 37 00 lea r15d,[rdi+r14]
46 8D 3C 37 lea r15d,[rdi+r14]
- MComplex without offset
8B 4C CA 00 mov ecx,dword ptr [rdx+rcx*8]
8B 0C CA mov ecx,dword ptr [rdx+rcx*8]
A small, nonexhaustive set of warning fixes. The DiscIO Volume change
is a workaround for a GCC bug [1] that causes returning an unengaged
std::optional to emit annoying -Wmaybe-uninitialized warnings.
This last change alone fixes pages upon pages of warnings since
Volume.h is included from several files.
-Wstringop-truncation is another irrelevant warning for us, but
unfortunately there seems to be no way to disable it without
adding ugly pragmas wherever the warning appears.
Removed conditional use of std::mutex instead of std::shared_mutex on MacOS.
Because MacOS < 10.12 did not support std::shared_mutex, a previous commit
naïvely substituted std::mutex, which does not have the same behavior.
Reverses PR #8273, which substitues std::mutex for std::shared_mutex on
macOS, and results in several bugs that seem to only affect MacOS
- https://bugs.dolphin-emu.org/issues/11919
- https://bugs.dolphin-emu.org/issues/11842
- https://bugs.dolphin-emu.org/issues/11845
This change eliminates conditional code for MacOS in the core configuration
layer code and enables the use of modern language features that are more
secure and thread-safe.
Previously the logging was a in a little bit of a disarray. Some things
were in namespaces, and other things were not.
Given this code will feature a bit of restructuring during the
transition over to fmt, this is a good time to unify it under a single
namespace and also remove functions and types from the global namespace.
Now, all functions and types are under the Common::Log namespace. The
only outliers being, of course, the preprocessor macros.
This is done by:
1) Implementing said protocol in a new controller input class CemuHookUDPServer.
2) Adding functionality in the WiimoteEmu class for pushing that motion input to the emulated Wiimote and MotionPlus.
3) Suitably modifying the UI for configuring an Emulated Wii Remote.
- Do not use a lambda for std::thread as invoke constructor exists
- Use simpler std::lock_guard wherever possible
- Do not require T to be default constructible
- Move T out of the queue instead of copying
- Fixed a bug where pushing items over queue's size left it in a corrupted state
- For non-trivial types, have clear() and pop() run destructors
- Added emplace(args...)
- Added empty()
FixedSizeQueue has semantics of a circular buffer,
so pushing items continuously is expected to keep overwriting oldest elements gracefully.
Tests have been updated to verify correctness of a previously bugged behaviour
and to verify correctness of destructing non-trivial types
API has been made stricter, layers are now managed with shared pointers,
so using them temporarily increased their reference counters.
Additionally, any s_layers map has been guarded by a read/write lock,
as concurrent write/reads to it were possible.
At its only usage point, its return value is stored into a u32, and the
default implementation returns 0xFFFFFFFF (-1), which would be an
unsigned integer. Given all of the bits are used to determine a color,
it makes slightly more sense to treat this as an unsigned value as
opposed to a signed one.
We're allowed (by the standard) to forward declare types within
std::vector, so we can replace direct includes with forward declarations
and then include the types where they're directly needed.
While we're at it, we can remove an unused inclusion of <cstring>, given
nothing in the header uses anything from it. This also revealed an
indirect inclusion, which this also resolves.
Previously u32 was being used for part of the interface and unsigned int
was being used for other parts. This makes the interface fully consistent by
using only one type.
We opt for u32 here given they communicate the same thing (for platforms
we care about where int is 32-bit), while also being less to read.
While we're at it, we can also default the constructor and destructor of
inheriting classes in their respective cpp file to prevent the
construction and destruction of non-trivial types being inlined into
other regions of code.
Previously these functions were declared without the static specifier,
giving them external linkage, which isn't really ideal.
Instead, we can place these functions up by the relevant file-scope
variables and place them inside an anonymous namespace with said variables,
giving them internal linkage.
Avoids the use of the null pointer to represent an empty string.
Instead, we can simply pass an empty string_view instance. Using
std::string_view enforces this invariant at the API level.
Due to the lack of cast here, this will actually print out the ascii
value, rather than the character itself, due to promoting to integral
values. Instead, we can eliminate the use of character operands and just
print the value itself directly, given it's equivalent behavior with
less code.
Allows these arrays to be placed within the read-only segment (and
enforces the immutability in the code itself). While we're at it, we can
make use of std::array here.
Now that the std::map less-than comparitor is capable of being used with
heterogenous lookup, we're able to convert many of the querying
functions that took std::string references over to std::string_view.
Now these functions may be used without potentially allocating a
std::string instance unnecessarily.
Previously, when performing find() operations or indexing operations on
the section map, it would need to operate on a std::string key.
This means cases like:
map.find(some_string_view)
aren't usable, which kind of sucks, especially given for most cases, we
use regular string literals to perform operations in calling code.
However, since C++14, it's possible to use heterogenous lookup to avoid
needing to construct exact key types. In otherwords, we can perform the
above or use string literals without constructing a std::string instance
around them implicitly.
We simply need to specify a member type within our comparison struct
named is_transparent, to allow std::map to perform automatic type
deduction.
We also slightly alter the algorithm to an equivalent compatible with
std::string_view (which need not be null-terminated), as strcasecmp
requires null-terminated strings.
While we're at it, we can also provide a helper function to the struct
for comparing string equality rather than only less than. This allows
removing other usages of strcasecmp in other functions, allowing for the
transition of them to std::string_view.
fmt diverges from printf in that '.' as a precision specifier may only
be used for floating-point values (makes sense, given it's indicating
precision after the decimal point).
Begins the transition to using fmt for string formatting where
applicable. Given fmt supports formatting std::string instances out of
the box, we can remove now-unnecessary calls to .c_str() and .data().
Note that this change does not touch the actual logging subsystem aside
from converting the final StringFromFormat call in the process over to
fmt::format. Given our logging system is heavily used throughout the
entire codebase, and converting that over will be quite a large change
by itself, this will be tackled near the end of the conversion process.
altimumdelta