What to do with cpp:S4963 when destructor is mandatory

[marco.b]

Hello @FlorentP42

@FlorentP42

Even having RAII thread objects in my class, I have no way to guarantee in what order they will be freed by a default destructor, do I?

Destructors are run in a deterministic manner in C++ but the order of element destruction in STL containers is not specified by the standard.

However, delete [] does delete objects in reverse order they were created. So depending on your implementation, the order for std::vector is fixed and appropriate for your use case. I would not advise relying on this implementation detail and instead creating a custom container class that handles destruction in the order you need. This helps keep classes smaller and abides by the single-responsibility principle (SRP), thus reducing maintenance burden and complexity.

In the same fashion, since you cannot use std::jthread, having a wrapper around std::thread that joins in its destructor helps follow the SRP. We link to a C++ Core Guildeline in C++ static code analysis: "std::jthread" should be used instead of "std::thread" that details this a bit more.

@FlorentP42

As I said above, sadly I cannot do that on Sonarcloud of public repositories, I do not have the ability to close a reported code smell as “won’t fix”, so there is no valid solution in my case with what you have suggested so far…

I missed this bit indeed. I would advise discussing with the owner of the repository to define a process to close these issues. If they want to give you permission to handle issues yourself, they can. See for example this thread which links to Managing user permissions in SonarCloud.

HTH