Some short guidance for adding sinks on the fly

[damienhocking]

We had a need to add a callback sink to our logs so we can reprocess log messages to different formats (json and MQTT) while keeping the original logging. I discovered a small gotcha. To add a sink, be careful how you access sinks() in the logger. This doesn't work:

auto sinks = log_->sinks();
sinks.push_back(std::make_shared<spdlog::sinks::callback_sink<std::mutex> >([this](const spdlog::details::log_msg& msg) {this->LogCallback(msg);}));

"auto sinks = ..." gives you a copy of the sinks vector. You're not modifying the sinks vector in the logger. You need to use auto& (or the original sink_ptr type defined in common.h, but it needs to be a reference to the vector):

auto& sinks = log_->sinks();
sinks.push_back( .....etc

Hopefully this saves someone else an hour of head-scratching.

[tt4g]

Wiki has a definition of spdlog::logger::sinks() and notes: https://github.com/gabime/spdlog/wiki/4.-Sinks#adding-sinks-to-the-logger-after-creation

And you can also use dist_sink: https://github.com/gabime/spdlog/wiki/4.-Sinks

[damienhocking]

Yes. That wasn't my point though. It's the compiler gotcha with auto, you get a vector copy, which isn't the actual sink vector in the logger.

[tt4g]

That is a C++ specification and spdlog cannot do anything about it.

[damienhocking]

OK. All I was trying to do was offer a suggestion for users who might need to add a sink and could get bitten by just using auto. It's not a spdlog bug, or a compiler bug, it's the C++ standard as you say.

[tt4g]

I misunderstood that you wanted to provide a workaround since it was not a discussion. My apologies.
Thank you for your contribution.

Since closed issues will no longer be viewed, I encourage you to edit the wiki and share your findings.

[damienhocking]

From now on I'll add things like this to the wiki (which is done). I'll close this.

[tt4g]

https://github.com/gabime/spdlog/wiki/Note-for-adding-sinks-on-the-fly