Store an owned pointer in MVEFILE instead of storing an unowned pointer
there and requiring the caller to keep the owned pointer alive for the
lifetime of the MVEFILE.
gcc-12 does enough escape analysis to notice that
newmenu::process_until_closed stores the address of a stack local into a
heap-allocated structure, but not enough analysis to notice that the
stack variable always outlives the escaped address. The compiler then
warns about the address escaping the local scope. Reworking the calling
code not to do this is somewhat invasive, and gcc seems unlikely to
change behavior. Switch to a less efficient implementation that does
not provoke a compiler warning:
- Store a shared_ptr<bool> in the object
- In the object's destructor, write through the pointer to clear the
shared boolean
- In the caller, store a copy of the shared_ptr<bool> as a local, and
use that copy to monitor the shared boolean
This is similar to a change proposed by JoeNotCharles
<10a2b2d337>,
but differs in its details. Among other things, this version takes the
opportunity to move the variable out to a mixin, so that only windows
which expect to be tracked can be tracked. Previously, all windows were
capable of this, even though most never needed it.
This is nullptr in all the cases that audio is disabled, and non-nullptr
in all the cases where it is enabled. Use it instead of a separate flag
variable.
The global variables that control it configure the callback to do
nothing, but SDL_mixer would still call it and still acquire the SDL
mutex that protects the call. Such calls are a waste, so disable them.
This should also fix
<https://github.com/dxx-rebirth/dxx-rebirth/issues/684>, which appears
to be caused by the MVE mixer callback being run during gameplay, and
the callback not returning immediately. This is suspected to be because
a race condition between MVE_rmEndMovie and the callback caused the
global variables not to be placed in a state that causes the callback to
return immediately.
OS X still uses clang-14, which lacks sufficient std::ranges support for
recent Rebirth changes.
- Rewrite uses of std::ranges::SYMBOL to ranges::SYMBOL
- Add a stub header that, on gcc, provides for each SYMBOL a statement
`using std::ranges::SYMBOL;`, to delegate back to the standard library
implementation.
- On clang, define a minimal implementation of the required symbols,
without constraint enforcement. Compile-testing with gcc will catch
constraint violations.
Once OS X clang ships a standard library with the required features,
this stub header will be removed and the uses changed back to their full
names.
gcc reports:
```
ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second
```
Fix the ambiguity by using an unsigned integer constant.
std::ranges::find_if permits use of a sentinel instead of a full
iterator, and supports std::ranges::find as an alternative to certain
simple uses of std::find_if.
Where possible, use the form that takes a range, rather than the form
that takes two iterators.
Add a declared, but not defined, default constructor for
self_return_iterator to satisfy the standard library's concept
`semiregular`, which insists that sentinels be default-constructible,
even for those functions that never need to do so.
Add a defined, but unused, operator++(postfix) for zip_iterator to
satisfy a standard library concept for `forward_iterator`.
