Every user now uses inheritance and a virtual function override. Make
callback_handler pure virtual, delete its body, and then delete the
member variables that existed only for use in that body. Remove the
constructor parameters that initialized those variables, and update all
derived classes accordingly.
The requirement to call send_creation_events from outside the
constructor makes the presence of a helper function convenient. Rename
ui_create_dialog to window_create, and move it to window.h.
For gcc bug #10138 [1], gcc-11 gained a new way to show a
-Wmaybe-uninitialized warning. When an uninitialized array is passed by
`const T *` to a function, gcc-11 assumes the array is an input to the
function, and warns accordingly. This is often useful, but is incorrect
for the Rebirth partial_range code. In this code, the pointer is only
passed so that the eventual exception can print the memory address of
the affected array. The called function does not dereference the
pointer, and so cannot be influenced by any uninitialized values in the
underlying array.
Change the report function to take the array address in a `uintptr_t`,
and cast it back for printing. This silences the gcc-11 warning, while
preserving the previous semantics in the code.
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10138
Previously, if SDL_AllocRW failed, then the handle would not be saved
into an SDL_RWops (since that object was not created), but it would also
not be closed immediately.
clang warns if all of:
- type T is deleted by a pointer T*
- T has a non-virtual destructor
- T has a virtual function
- T is not final
Fix the build by making the relevant types T final, since nothing
inherited from them.
Kreeblah reports that clang now warns for powerup.cpp due to a missing
__attribute_format_printf. This was incorrectly dropped in
ffb653c0b8. gcc did not warn, but clang
now warns. Add back the attribute.
Fixes: ffb653c0b8 ("Pass control_info & to various functions")
Reported-by: Kreeblah <https://github.com/dxx-rebirth/dxx-rebirth/pull/547>
Due to ordering constraints, this is not merged into MENU, but is
instead kept as a distinct sub-type that is pointed at by MENU. MENU
sets the window's position based on parsing of the menu definition file,
but the parser expects to store window position data into MENU before
creating the window. If menubar_window were merged into MENU, the
parser would need a temporary, and all callers that create the window
would need to consult that temporary.
All callers request either the menubar or something else, but never
conditionally request one or the other. Split the special handling that
picks a different handler based on which element the caller requested.
