Split the test into several parametrised tests for each data type.
Add more tests with different values.
Fix the ReadBinary() function in order to fix the ReadDouble() function
for negative values (the sign bit was being lost).
Fix mistakes after previous merge and make it compile.
Rewrite the function interpolating between time stamps as it was
written after the original pull request was created. Add unit tests
for it.
I couldn't help myself and also changed some enums to enum classes and
did some renames.
-Wmissing-declarations enforces that every function (except for static
functions) must be declared separately before it's defined. This
essentially enforces that every function must be either static, or
declared in a header elsewhere.
This helps the optimizer, as it can do a better job of inlining if it
knows that a function won't be used outside of a given file. It also
helps -Wunused-function (which is enabled by -Wall) find more unused
functions.
Note that Clang spells this option -Wmissing-prototypes, which
confusingly is the name of a related but different warning option under
GCC.
SystemTimeStamp used to be an opaque class, as it was provided by
`system_{linux/other/windows}.h`. Because of this, code dealt in
SystemTimeStamp pointers, and getting the current timestamp required a
memory allocation. Now SystemTimeStamp is just a
`std::chrono::time_point`, we can make the code cleaner and faster by
just directly keeping SystemTimeStamp instead of pointers around.
Clang by default compiles with -Winconsistent-missing-override, which
warns when a class declares virtual functions that override those in the
base class, and some but not all of them are explicitly declared
`override`.
GCC doesn't support this option, but has a stronger version,
-Wsuggest-override. In combination with -Werror, this means that any
virtual function that overrides another *must* be explicitly declared as
`override`.
This commit enables -Wsuggest-override where available. This means that
GCC users can't break the Clang build with inconsistent overrides (see
#1113 and #1114) and consequently that any build that passes the pull
request CI build on Jenkins won't break because of inconsistent
overrides.
Tomasz Kapuściński
immibis