A simple logging system

[zhuzhile08]

Alright, any coding project is going to need a logging system in some way or shape, which I've agreed to implementing it in this project. As suggested by Karnage, I'm going to use the FMT library for this purpose.

Here are some design features/principles behind this logger:

• Free floating functions in a namespace
• A C-inspired interface
• An interface which will not require any direct references to the FMT library
• Colored text with different logging levels (pretty much the standard for loggers)

if you should have suggestions regarding the design of the logger, please leave them in the comments, as I will start the implementation of the logger tomorrow.

Estimated duration until completion: 2 days.

[karnkaul]

C inspired

I would say no to this. The core function should just call fmt functions, wrappers on top will perhaps do custom formatting (thread, severity / level, timestamp, etc) and then call that.
Here's an example you could reference, ignore all the extra machinery, just focus on the error(...), warn(...), info(...), etc primary interfaces.

[zhuzhile08]

Yeah, no problem, thanks for the example!

[karnkaul]

Demo example that just forwards everything through fmt:

template <typename... Args>
std::string format(fmt::format_string<Args...> fmt, Args const&... args) {
	return fmt::vformat(fmt, fmt::make_format_args(args...));
}

[zhuzhile08]

Yeah, makes sense

I personally would probably just leave a bit of "space" between the user calls and the FMT library call, so that is room for future features and extensions. May require me to take out my Design Patterns book again 🤣.

[zhuzhile08]

What I specifically mean by this, is maybe to have a base class with no implementation, and have the user all a function that takes a pointer to this base class, and then there may be multiple implementations, like one with console outputs, one with terminal outputs and so on. I think this was called a bridge?

[karnkaul]

I personally would probably just leave a bit of "space" between the user calls and the FMT library call, so that is room for future features and extensions.

That is great forward thinking! It's unfortunately too complicated to type erase the arguments for fmt, and if we do that we will lose compile time parameter checking, which is a great feature of fmt. In this case we should just make an exception and tightly couple the dependency to the rest of game code. Just like with SFML TBH.

[zhuzhile08]

tightly couple the dependency to the rest of game code.

Would you mind going into a bit more detail? I didn't quite understand what you mean, sorry.

[karnkaul]

tightly couple the dependency to the rest of game code.

Would you mind going into a bit more detail? I didn't quite understand what you mean, sorry.

It just means the interface will "know" about fmt and use it directly, instead of an abstract base class like indirection.

[zhuzhile08]

Hmm, alright, thanks, guess I'll have to look a bit more into the library to really understand it, but I get what you mean now. Maybe I can implement some shape of abstraction, overloading everything to be compatible with file logging kinda sounds annoying 😅.

[karnkaul]

Hmm, alright, thanks, guess I'll have to look a bit more into the library to understand it better.

Ah if you haven't used fmt before let's shorten the scope of this Issue to just integrating that and adding a wrapper function. That can be expanded upon to include levels, timestamps, sinks, etc in future issues.