Do C++ logging frameworks sacrifice reusability?

Question

In C++, there isn't a de-facto standard logging tool. In my experience, shops roll their own. This creates a bit of a problem, however, when trying to create reusable software components. If everything in your system depends on the logging component, this makes the software less reusable, basically forcing any downstream projects to take your logging framework along with the components they really want.

IOC (dependency injection) doesn't really help with the problem since your components would need to depend on a logging abstraction. Logging components themselves can add dependencies on file I/O, triggering mechanisms, and other possibly unwanted dependencies.

Does adding a dependency to your proprietary logging framework sacrifice the reusability of the component?

Answer 1

Yes. But dependency injection will help in this case.

You can create an abstract logging base-class and create implementations for the logging-frameworks you want to use. Your components are just dependent on the abstract base-class. And you inject the implementations along with al their dependencies as needed.

Answer 2

Yes, Mendelt is right. We do exactly this in our products. Everything depends on the ILogger abstract interface, but it does not depend on anything else. Typically an executable or a high-level DLL will be the one to construct an actual implemented Logger interface and inject it.

Answer 3

If you are looking to build libraries which wont be recompiled, but want to provide a logging interface then perhaps a good way is to allow the user (of the library) to provide a callback.

On initialising logging with your library, they would need to specify the callback, and then the glue-code is up to them to make it play well with whatever they have.

If you can make the signature of the callback look like a standard function they might always have available to them, it provides them an easy default option if they dont actually have a logger.

Additionally the caller might have instanced components from the library multiple times, and for resource contention or threading issues, want to provide a different logger callback for each one.