Explicitly initialize all member variables
kcgen opened this issue · comments
The DOSBox Staging team is working on putting your excellent filter to use.
It's very clean warning-wise (nice work!) - but we're getting one type of warning from GCC (admittedly non-critical) regarding some missing class member initializers.
https://github.com/dosbox-staging/dosbox-staging/runs/6524236279?check_suite_focus=true
Many of the IIR1 class members do have initializers, like biQuad's:
double m_a0 = 1;
double m_a1 = 0;
double m_a2 = 0;
double m_b1 = 0;
double m_b2 = 0;
double m_b0 = 1;These are the warnings we're getting:
../include/../src/libs/iir1/iir/Layout.h:65:17: warning: 'Iir::LayoutBase::m_pair' should be initialized in the member initialization list [-Weffc++]
../include/../src/libs/iir1/iir/PoleFilter.h:115:3: warning: 'Iir::PoleFilter<Iir::Butterworth::LowPassBase, Iir::DirectFormII, 16, 16>::m_analogStorage' should be initialized in the member initialization list [-Weffc++]
../include/../src/libs/iir1/iir/PoleFilter.h:115:3: warning: 'Iir::PoleFilter<Iir::Butterworth::LowPassBase, Iir::DirectFormII, 16, 16>::m_digitalStorage' should be initialized in the member initialization list [-Weffc++]
../include/../src/libs/iir1/iir/PoleFilter.h:59:17: warning: 'Iir::PoleFilterBase2::m_digitalProto' should be initialized in the member initialization list [-Weffc++]
../include/../src/libs/iir1/iir/PoleFilter.h:89:17: warning: 'Iir::PoleFilterBase<Iir::Butterworth::AnalogLowPass>::m_analogProto' should be initialized in the member initialization list [-Weffc++]
../include/../src/libs/iir1/iir/Types.h:104:17: warning: 'Iir::PoleZeroPair::poles' should be initialized in the member initialization list [-Weffc++]
../include/../src/libs/iir1/iir/Types.h:104:17: warning: 'Iir::PoleZeroPair::zeros' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/Butterworth.cpp:72:1: warning: 'Iir::Butterworth::AnalogLowShelf::m_gainDb' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/ChebyshevI.cpp:43:1: warning: 'Iir::ChebyshevI::AnalogLowPass::m_rippleDb' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/ChebyshevI.cpp:96:1: warning: 'Iir::ChebyshevI::AnalogLowShelf::m_gainDb' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/ChebyshevI.cpp:96:1: warning: 'Iir::ChebyshevI::AnalogLowShelf::m_numPoles' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/ChebyshevI.cpp:96:1: warning: 'Iir::ChebyshevI::AnalogLowShelf::m_rippleDb' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/ChebyshevII.cpp:46:1: warning: 'Iir::ChebyshevII::AnalogLowPass::m_stopBandDb' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/ChebyshevII.cpp:96:1: warning: 'Iir::ChebyshevII::AnalogLowShelf::m_gainDb' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/ChebyshevII.cpp:96:1: warning: 'Iir::ChebyshevII::AnalogLowShelf::m_stopBandDb' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/Layout.h:65:17: warning: 'Iir::LayoutBase::m_pair' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:106:1: warning: 'Iir::HighPassTransform::f' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:140:1: warning: 'Iir::BandPassTransform::a' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:140:1: warning: 'Iir::BandPassTransform::a2' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:140:1: warning: 'Iir::BandPassTransform::ab' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:140:1: warning: 'Iir::BandPassTransform::ab_2' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:140:1: warning: 'Iir::BandPassTransform::b' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:140:1: warning: 'Iir::BandPassTransform::b2' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:140:1: warning: 'Iir::BandPassTransform::wc' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:140:1: warning: 'Iir::BandPassTransform::wc2' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:224:1: warning: 'Iir::BandStopTransform::a' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:224:1: warning: 'Iir::BandStopTransform::a2' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:224:1: warning: 'Iir::BandStopTransform::b' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:224:1: warning: 'Iir::BandStopTransform::b2' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:224:1: warning: 'Iir::BandStopTransform::wc' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:224:1: warning: 'Iir::BandStopTransform::wc2' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/PoleFilter.cpp:59:1: warning: 'Iir::LowPassTransform::f' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/Types.h:104:17: warning: 'Iir::PoleZeroPair::poles' should be initialized in the member initialization list [-Weffc++]
../src/libs/iir1/iir/Types.h:104:17: warning: 'Iir::PoleZeroPair::zeros' should be initialized in the member initialization list [-Weffc++]
These can typically all be set to 0, false, nullptr, (or = {}; for complex types). The default initializers are safe-fallbacks covering all the avenues that a class object may come into existence (through copy constructors, default constructors, and so on), even if the as-implemented code is careful not to use these.
https://stackoverflow.com/questions/11496942/understanding-weffc
I never heard of that option before and had to look it up. As the stackoverflow article states it's just a very dumb checking mechanism. For example ../src/libs/iir1/iir/PoleFilter.cpp:106:1: warning: 'Iir::HighPassTransform::f' should be initialized in the member initialization list [-Weffc++] this error message is pointless because f is directly initialised in the constructor so will never be an issue.
Also when doing "man gcc" and searching for that option is reports that even the standard libraries will throw up warnings.
I'd be happy to receive a pull request but that's just a lot initialisation just for the sake of it. For example the frequency variable f won't even make sense if set to zero and would cause a division of zero somewhere.
I'm sorry but I'm not fixing these warning just to make them disappear and your compilation fails because of code not being part of iir1. If you find really an uninitialised value which causes trouble then let me know. Otherwise I'll close it.
I'd be happy to receive a pull request but that's just a lot initialisation just for the sake of it.
Thanks @berndporr ; PR inbound.
For example the frequency variable f won't even make sense if set to zero and would cause a division of zero somewhere.
The default initializers will only show through when no other assignment was performed; so my guess is all of your existing code paths are already assigning a valid f prior to the division taking place.
But in the rare chance it does divide by zero (due to using the default initializer), then it will reveal that the code is currently dividing by an uninitialized value, possibly leading to undefined behavior. (In which case weighing the two scenarios, crashing is considered safer, because it reveals a bug and avoids unexpected behavior).
That said, I think all is well in your code because the PR is working just as well as the existing release (testing in DOSBox Staging).
PR applied. Thanks. See my comments there.