QT_TO_UTF8 returns a const char * that, in general, shouldn't be stored.
This is because QT_TO_UTF8(str) expands to str.toUtf8().constData():
toUtf8() returns a QByteArray, and constData() the pointer to its data
which is only valid until the QByteArray goes out of scope, which is
immediately after the call.
The original code that is changed here only works because in all of the
situations, the object that is stored to is actually a std::string that
gets constructed implicitly, so the constData() pointer is valid long
enough for the std::string constructor to copy the data.
The issue is that any "... = QT_TO_UTF8" code *looks* unsafe, and may
lead new or unfamiliar contributors to assume that they can also use it,
only to do "const char *... = QT_TO_UTF8(...)" which is dangerous.
Additionally, it introduces an unnecessary round of implicit conversions
and copies when QString.toStdString() already exists and copies into the
string buffer directly.
Implicitly capturing "this" with the capture default "=" is deprecated
with C++20. We fix this by either explicitly passing this, or by copying
the required members manually.
While this exposes some rather expensive copies like the QList
selectedItems in OBSBasic_Preview, it doesn't introduce them ("=" copies
implicitly).
Implicit capture of 'this' with a capture default of '=' is deprecated
in C++20.
# Conflicts:
# frontend/settings/OBSBasicSettings.cpp
# frontend/settings/OBSHotkeyEdit.cpp
# frontend/settings/OBSHotkeyWidget.cpp
SetComboByName, SetComboByValue and SetInvalidValue all pass their
parameters to Qt functions which only take QStrings. As a consequence,
we have cases we'd convert a QString to a const char* to call these
functions, only for the functions to implicitly convert them back into
QStrings. We can avoid this by passing QStrings directly. In cases where
we did actually pass const chars, the (implicit) conversion now just
takes place earlier.
This removes the need to provide an undocumented launch argument to
enable custom RTMP service configurations to use multitrack encoding
and also provide a custom configuration.
While the Metal renderer is displayed as "Metal (Experimental)", the
"Experimental" part doesn't need to be stored to the config. Otherwise,
anyone having selected the Metal renderer will have it get unselected
once the "Experimental" part is removed, and presumably the people who
have it selected while it's experimental would also be the people who
would want it once it's stable.
