wangjunZeroZeroSeven

`std::shared_ptr` only controll the lifetime of spdlog logger, but it can't controll these basic things: the `s_mutex` in : ``` struct console_mutex { using mutex_t = std::mutex; static mutex_t &mutex()...

Unfortunately that's exactly our case :-) In our project , we use a static container to hold most of our objects as members. So it's somehow a special case, if...

Actually, force all basic things to live longer than spd logger is viable and will be more safe and save lots of exceptions, but it's annoying which I understand .

Making the lifetime of other objects shorter than spdlog is easy, but making the lifetime of other objects shorter than all the basic things that spdlog relies on is difficult...

According to these pages: [Destruction order of static objects in C++](https://stackoverflow.com/questions/469597/destruction-order-of-static-objects-in-c) [std::exit](https://www.enseignement.polytechnique.fr/informatique/INF478/docs/Cpp/en/cpp/utility/program/exit.html) It is illustrated that static variables will destruct in the reverse order of construction, so what we can...

All local static objects declared in a function scope will construct when the first time we call this function, so it's hard to say these variables will initialize when program...

Some static local varaibles that spd logger relies on may be not used when initilizing spd logger, they may be first used when we first log, or may be first...

@SirWhiteHat I have to point out that it's not absolutely safe either, as you can controll the life cycle of `spdlog` instance, but you cannot controll the basic static variable's...