| Age | Commit message (Collapse) | Author |
|---|
|
- use `static constexpr inline' to avoid requiring
explicit declarations in object code
- use `const Foo* const' to maybe put into readonly
binary segment (at least for ELF DSOs)
- `constexpr' in function scope has storage, avoid
`static'
- don't use `constexpr' where there's no advantage,
like arrays
We'd like to avoid overhead of atomic initialization
for each function call. No idea how `static constexpr'
requiring storage in the standard plays with atomic
initialization requirement. Hearsay points that
`constexpr' without `static' in block scope behaves
more to our liking. It's all hazy though.
I'm not 100% sure if `static inline constexpr' has any
storage. Hopefully none, like a #define, and stuff
bigger than registers gets coalesced within the same
module, with small stuff being immediates.
|
|
Adjust usages.
|
|
|
|
|
|
|
|
- indent
- use clamp from util.hpp
- rename vaguely-named variables
|
|
We heavily used "volatile bool" to check if the thread
loop should stop. But this functionality is already
provided by Qt5's QThread::requestInterruption.
In other cases, "volatile" is wonderfully
underspecified so it's better to ditch its usage in
favor of std::atomic<t>. At the time we don't appear to
be using the "volatile" keyword except when calling
win32's Interlocked*() family of functions as
necessary.
In freetrackclient's header the "volatile" qualifier
was used as part of a typedef. This doesn't work. Use
it as part of data declaration.
|
|
|
|
With -D_USE_MATH_DEFINES MSVC defines the standard M_PI and
friends.
Since this preprocessor definition is now always passed as part
of the build system for MSVC. We can use M_PI as if on a
mission.
|
|
Adjust usages.
|
|
We can't depend on M_PI existing after including cmath.
|
|
|
|
Closes #224
|
