Refactor Logging Mechanism

[rkowalewski]

The logging mechanism in our header library suffers from several issues:

1. Our Logging macros log always complete objects which can be both of simple datatypes and classes. Either way it requires that operator<< is a well-formed expression. Since we excessively log basically everything this can lead to compilation problems in our container library if operator<< is not appropriately provided by the user. See #594 as an example which logs the value type of our container.
2. As a consequence, our logging macros are inflexible. Users are not able to provide stream expressions themselves (the way how IO works in C++) and our macros are not type safe.
3. The current logging implementation has very low performance which is annoying during development and debugging sessions.

The first point is difficult to address, we either have to check via TMP if operator<< is available, or we do it only for plain old datatypes (which is straightforward via std traits), or we simply never log any value types in our containers.

Points 2 and 3 can be addressed as explained in another issue. See also a thread on Stackoverflow for a more detailed discussion.

I implemented this approach in a DASH application and it is very fast, assembly is reduced by 50% compared to our current logging mechanism, it is type safe and it provides way more flexibility for us. since we can pass streams to the logging macros.

Replacing the whole logging mechanism would break our library. However, what we can do is to implement the new approach, redirect our current logging macros to the new implementation and do a smooth transition. If we have some voluntaries, in particular one of our students, we can give it a try.

[fmoessbauer]

Just a note: In another project I faced similar problems and did some research. There are two pretty good libraries related on this topic:

• gabime/spdlog: Fast extensible logger (uses fmt)
• fmtlib/fmt: Typesafe and fast formatting lib

The big caveat with spdlog is that it uses mutexes (in construction of the logger) and exceptions when logging. Finally I decided to use spdlog when mutexes and exceptions are possible. On the other places, I used a combination of fmt and your approach described above.

[rkowalewski]

spdlog seems to be a very good IMHO. ;)