This is not so cosmetic: Moved init() chores from connect() to the constructor for consistency with other implementations. Not relevant here since files are not processed in real-time, but is it common practice in other blocks to set everything needed (and get all the resources) in the constructor, before connect()
Moved the constructor code to the top of the file, also for consistency with other files. This is an opinionated practice, I know, since one could expect the same order than in the header file.
Improved comment formatting for Doxygen
Added and removed some blank lines to match the style of other files (two blank lines within method implementations, no two consecutive blank lines inside the method. Again opinionated, but for the sake of consistency.
Included the <tuple> library (include what you use)
some of these are ridiculous and so have been silenced. I'm a huge fan
of static code analysis but I have a hard time believing that writing
"0U" is a qualitative improvement over "0u".
I'm not sure that there is any value in continuing with a bad configuration
but be careful about changing the semantics of existing code. You never know
what else may depend upon it.
This was much worse than I thought. I had run clang-format at some point, but
apparently I subsequently made some non-compliant changes in pretty much every
file I touched.
I don't know how this didn't run before submitting the PR. CI tests are great!
The file-based signal sources were modified to not throw an exception on creation
but rather when connect() is called. The unit test was checking for an exception
upon construction.
The existing CMake logic is broken-ish; or rather log4cpp is broken-ish, and
this inhibits the use of C++17 std::filesystem.
All of the static libraries created are brittle; consider changing from
STATIC to OBJECT in the future?
