| Age | Commit message (Collapse) | Author |
|---|
|
The API is obsolete as well as the device.
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
The initial version won't have a generalized spline
with multiple parameters to configure the gain. But
it's doable in one go unlike a fully-fledged version
from the start.
|
|
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.
|
|
|
|
|
|
|
|
It doesn't work good enough.
Try use splines instead.
|
|
|
