Casting to void should shut up GCC about
error: statement has no effect [-Werror=unused-value]
static_cast<void>() is possible for all current types. Supposedly an old
C style cast could also be used, but they should not be used in modern
C++ code.
GCC gave error
../src/tabcontrollers/MoveCenterTabController.cpp:57:67: error:
operation on
‘((advsettings::MoveCenterTabController*)this)->advsettings::MoveCenterTabController::lastMoveButtonClick[0]’
may be undefined [-Werror=sequence-point]
Because assigning a value to itself twice is undefined behavior. It is
highly likely that intended behavior was to initialize both array
members to the same value at once.
Mostly casts and unsigned to signed comparisons.
Testing to ensure that the int isn't below 0. If it is, it can't be used
in the array later anyway. After we're sure it isn't below 0 it's safe
to static_cast<size_t>().
Currently with /W3 on MSVC there are no warnings. Clang and g++ are not
tested.
The "QMAKE_CFLAGS_WARN_ON -= -W3" and "QMAKE_CXXFLAGS_WARN_ON -= -W3"
are necessary because if they are not removed in the config, the
compiler will give D9025: overriding '/W4' with '/W3' error warnings and
not actually use /W4.
apperror was shadowing another variable in the scope outside of the if
statement, leading to a warning.
Adding an underscore changes the var name without changing the meaning.
In the future a different structure should probably be chosen for the
statements.
The warnings in dummy functions are preventing the project from being
compiled with warnings as errors.
There were two options:
* Using a define to create a noop (chosen option).
* Commenting out the variable name, leaving only the type.
The first option was chosen because the second option would leave out
information from the IDE and compiler, while the first option wouldn't.
The intent is also clearer with the first option, otherwise it would
likely be necessary to leave comments with every single parameter that
was commented out.
Currently the variable expansion sometimes doesn't work when done over
two variables. Inlining the ~dp0 call along with \..\..\ seems to work.
Testing leads me to believe that the Windows command prompt caches
things in a weird way.
The old build scripts used hard coded directory paths, didn't check if
the paths actually existed and didn't differentiate between compiling,
deploying libraries and packaging for release.
The new build scripts are split into three different files. They are all
longer than the old build scripts, but most of the extra lines are
error checking, which the old one lacked.
It was considered writing the build scripts in another language like
Python or Powershell, but the relatively small size of the project and
unlikelihood of the build systems needing to grow massively means that a
very simple imperative language like the Microsoft scripting language is
fine.
The current readme lacks a table of contents, which makes finding what
you're looking for difficult because of the large amount of images and
text.
The current documentation on building for windows doesn't mention the
fact that package.cmd also has to be run to create a full build. It is
also lacking in other areas, such as the packaging programs required.
The current documentation doesn't reflect the fact that you can pass
command line arguments to the program.
The install/remove manifest logic in main is currently duplicated. This
bloats up main and creates unnecessarily large indented logic. The only
thing that is different between the two large if blocks is a single
function call.
Refactoring to test for which function to call at the latest possible
stage reduces code duplication.
The command line argument parsing is done in a giant for loop in the
main function. This presents readability and extension problems.
Refactor the big for loop into smaller loops inside the function.
In theory this will affect performance slightly at startup, but when considering
the very low amount of possible command line arguments (5, currently) and the low
amount of arguments being passed on a typical launch (0 or 1, mostly),
the readability improvements are very much worth it.
The string literals have also been moved to the "argument" namespace as
constexpr, in order to avoid potential typos in string literals.
Should the amount of command line arguments increase severely, it might
be necessary to create a structure with only one pass through the
argument loop, but such a situation is very unlikely.
Vasily
Robin Appelman
ykeara