Since you said "C++17", consider rewriting all your void foo(const std::string& s) signatures into void foo(std::string_view sv) signatures. (Yes, pass string_view by value. pass string_view by value.)
Since you said "C++17", consider rewriting all your void foo(const std::string& s) signatures into void foo(std::string_view sv) signatures. (Yes, pass string_view by value.)
Since you said "C++17", consider rewriting all your void foo(const std::string& s) signatures into void foo(std::string_view sv) signatures. (Yes, pass string_view by value.)
- Is my code thread safe? If not, how do I make it thread safe?
No, of course it's not thread-safe. You don't do anything to make it thread-safe.
A more nuanced answer would be: It's thread-safe as long as you don't use it in an unsafe way. For example, calling Logger::log(FATAL, "hello world") from two different threads concurrently would of course be unsafe. But if your program has only one thread... :)
If you want to allow calling Logger::log from two threads concurrently, you'll have to do something to eliminate the data race on m_logfile which is caused by the two threads' both calling m_logfile << levels[static_cast<int>(s)] at the same time. For example, you could throw a mutex lock around addLog.
- Is there a way to make the interface a bit cleaner for use? Right now
#definefeels a bit hacky.
The only place you use #define is in #define FATAL Logger::Level::Fatal and so on. (By the way, technically #define ERROR ... triggers undefined behavior, because all macros of the form EXXXX are reserved for use by POSIX error codes.) My question is, if you wanted these values to be referred to as FATAL, ERROR, etc., why didn't you just declare them that way?
inline constexpr int FATAL = 0;
inline constexpr int ERROR = 1;
inline constexpr int WARNING = 2;
// ...
Or, probably better:
namespace Logger {
enum Level {
FATAL, ERROR, WARNING, // ...
};
}
Making this an enum (rather than an enum class) allows your user to refer to the enumerators without needing to redundantly name the enum type: just Logger::FATAL, Logger::ERROR, et cetera.
Personally, I would consider writing convenience functions to eliminate the boilerplate:
namespace Logger {
void log_fatal(const std::string& msg) { log(FATAL, msg); }
void log_error(const std::string& msg) { log(ERROR, msg); }
// ...
}
By the way, I think your numbering scheme is backwards. "Level" represents the severity of the message, right? Some messages have higher severity than others? So how would I test whether one message had a higher severity than another? Well, I think I'd write:
if (one_severity > another_severity) ...
But with the values you gave your enumeration, this is actually going to be completely backwards! And so my code for testing severity levels is going to have a bug (or else I'll catch the bug, but then have to write unintuitive code that uses < to mean "greater than"). So, I recommend switching the values around.
- Is there a way to avoid the use of a global
unique_ptr?
Sure; declare it static! And to make it really non-global, stick it in a function. It'll still have static lifetime, though. There's not much getting around that.
inline Log *get_glog() {
static std::unique_ptr<Log> glog = std::make_unique<Log>();
return glog.get();
}
void startLog(const std::string& filepath) {
Log *glog = get_glog();
glog->set_filepath_and_open(filepath);
}
- Should I just make it a header only library? Is there any benefits in doing so?
The big benefit of a header-only library is that it's super easy to incorporate into another project — the user just drops the header file into his include/ directory and he's good to go.
Single-header libraries are particularly nice because they can easily be dropped into Godbolt or Wandbox.
In your case, the tradeoff is that presumably this header is going to get included all over the place (because logging is ubiquitous), and so the bigger you make it, the more work you're forcing the compiler to do in every translation unit.
Since you said "C++17", consider rewriting all your void foo(const std::string& s) signatures into void foo(std::string_view sv) signatures. (Yes, pass string_view by value.)