Thanks for the feedback! spdlog is friendly with multi threaded code. In fact, I currently use in the PR (as viktor suggested) an async logger, which does the logging in a different thread altogether.
Regarding the exposure of spdlog, I can add the functionality for directing streams to files, and we might discuss what other functionality is expected. However, exposing spdlog would give a huge amount of flexibility, as you can easily do whatever you want, thanks to their amazing interface and built-in sinks. Note that getting rid of macros means getting rid of source location (line, function, and file name). On Mon, Jul 22, 2019 at 11:24 PM Heiko Strathmann < heiko.strathm...@gmail.com> wrote: > Hi! > > Great initiative! See below > > Am Mo., 22. Juli 2019 um 19:49 Uhr schrieb Ahmed Essam < > theartful...@gmail.com>: > >> Regarding using spdlog, here are the assumptions: >> 1. There will be only one global SGIO object for logging. >> > Similar problems as for random: This means that multithreaded code will > also use this for logging, and we will need some sort of critical around > the log output. I wonder how that would affect performance. Also I wonder > how other (multithreaded) libs do this? Some minimal research might be good > here. > > >> 2. Two streams are used: stdout (for all log levels except for MSG_ERROR) >> and stderr, and the user can direct any of them. >> > That sounds very reasonable > > 3. spdlog will be exposed. That is the user will use spdlog sinks to >> redirect streams. I don't see a reason to wrap around them or add options >> to manipulate them further. Exposing spdlog is more flexible. So we can use >> "dist_sink" for example to redirect to multiple sinks. >> > I am not too sure about this. Backend libraries tend to change over the > years and explicitly adding those into the codebase usually causes > headaches later on. So I'd actually prefer some plugin like thing, but I > can probably be convinced ;) > > >> >> Some questions: >> 1. Are these assumptions reasonable? >> 2. Should we use fmtlib? I currently format using sprintf, but fmtlib is >> supposedly similar in runtime speed, and adds a little overhead in compile >> time (header library with compile time format checking!). The downside (for >> us) is that it uses python-like formatting. >> > Seems fine to me > > >> 3. Should we get rid of macros? >> > I think that would be nice. I guess they were used to switch off things at > compile time. We don't really do that anymore. > >
