C++17/20 compatibility? about zep HOT 2 CLOSED

As I mentioned on the PR, my preference is that zep be widely deployable to my projects as they stand, without needing to force compiler upgrades. Supporting multiple compiler standards is less attractive to me than deployability, so I'd prefer to see those structures in the rapidly evolving portions of std avoided through the use of less modern features. #ifdef'ing around std and language differences means that issues can fall through the cracks unless someone is testing and maintaining the variants across compilers and compiler versions. Regressing the affected code to less modern features would avoid that. I realize that has a knock on effect, so it's not a trivial suggestion, but I think chasing standards is also not trivial, over the long term.

from zep.

I'm somewhere in the middle here! I like to be able to use the more modern features, and I'm all for fixes that work with C++17/20. On the other hand, as @meshula noted, I have tried to keep Zep working on most compilers.
The change to signals is actually to a shared library; so no real knowledge of what the right thing to do there is; the PR looks fine for me. I should add attribution to the header here (it is MIT, but the right thing to do): https://github.com/fr00b0/nod
The same thing for the threadpool; I didn't write it, but that fix looks OK to me.
The explicit on the MString is obviously the right thing to do; and I need to be better about using that keyword.

As you can see, the heavy STL/template usage is usually in shared bits; I don't favour this style of coding myself; I find it hard to update/understand. So I think these fixes are OK, given their location and the needs of @nicolasnoble

from zep.