Potential fix for 1 code quality finding

[ann0see]

This PR applies 1/2 suggestions from code quality AI findings. 1 suggestion was skipped to avoid creating conflicts.

Not yet reviewed. We may want to check if this is a valid finding even.

[ann0see]

Needs review...

[softins]

After some thought, I've concluded that it is because CThreadPool has two constructors:

• CThreadPool() = default
• CThreadPool(size_t)
  and only the size_t version has a constructor initialisation for stop(false), a few lines further down. The default constructor doesn't, and therefore if that constructor were used, stop would start uninitialised.

In fact, it would appear that in the code, the CThreadPool constructor is only ever called with the size_t argument, in server.cpp.

So in that case, instead of the above in-class initialisation, I would remove the default constructor declaration and check that the code still compiles (it should, unless I've overlooked something).

[softins]

So in that case, instead of the above in-class initialisation, I would remove the default constructor declaration and check that the code still compiles (it should, unless I've overlooked something).

Yes, I've tested compilation with the line CThreadPool() = default; removed, and it still builds fine. So I would recommend that is the best solution, as it doesn't seem to make sense to create a thread pool without specifying a number of threads.

[mcfnord]

If one of the two constructors is never needed, removing the unused option makes sense to me.

Also, Gemini mentions Brace Initialization, introduced in C++ v11, which assures zero-initialization.