Implementing a logging system in C++17












2












$begingroup$


I've been programming for what is a probably a little bit and made a very simple logging system for my personal projects. While it works out fairly well so far, I would like advice on how to make it perform better and stuff I can do to make it more usable in general.



Main questions include:




  1. Is my code thread safe? If not, how do I make it thread safe?


  2. Is there a way to make the interface a bit cleaner for use? Right now # define feels a bit hacky.


  3. Is there a way to avoid the use of a global unique_ptr?


  4. Should I just make it a header only library? Is there any benefits in doing so?



.hpp:



#pragma once

/*
Use it by including this header in every file required, and in your main function start a new log.
Logger::startLog("Log.txt");
Use the various error levels by naming them and simply passing the info and what you want to output.
Logger::log(ERROR, "Something went wrong.");
*/

// For the unique pointers.
#include <memory>
// Filestream.
#include <fstream>
// String class for names and parameters passed around.
#include <string>

#define FATAL Logger::Level::Fatal
#define ERROR Logger::Level::Error
#define WARNING Logger::Level::Warning
#define INFO Logger::Level::Info
#define DEBUG Logger::Level::Debug

namespace Logger {
// Severity level enum.
enum class Level {
Fatal,
Error,
Warning,
Info,
Debug
};

// Initialize the log.
void startLog(const std::string& filepath);

// Log a message.
void log(Level s, const std::string& msg);

// Logging class.
class Log {
public:
Log(const std::string& filepath);
void addLog(Level s, const std::string& msg);
~Log();
private:
// File for logging.
std::ofstream m_logfile;
std::string levels[5] = {"Fatal", "Error", "Warning", "Info", "Debug"};
};
}


.cpp:



#include "Log.hpp"

namespace Logger {
// Global Logging Object.
std::unique_ptr<Log> g_log;

// Initalize our logging object.
void startLog(const std::string& filepath) {
g_log = std::make_unique<Log>(filepath);
Logger::log(Level::Info, "Started logging system.");
}

// Method which logs.
void log(Level s, const std::string& msg) {
g_log->addLog(s, msg);
}

// Create our global logging object.
Log::Log(const std::string& filepath) : m_logfile{} {
m_logfile.open(filepath);
}

// Add a message to our log.
void Log::addLog(Level s, const std::string& msg) {
if (m_logfile.is_open()) {
m_logfile << levels[static_cast<int>(s)] << ": " << msg << std::endl;
}
}

Log::~Log() {
addLog(Level::Info, "Stopped logging system.");
m_logfile.close();
}
}









share|improve this question









New contributor




Rietty is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







$endgroup$

















    2












    $begingroup$


    I've been programming for what is a probably a little bit and made a very simple logging system for my personal projects. While it works out fairly well so far, I would like advice on how to make it perform better and stuff I can do to make it more usable in general.



    Main questions include:




    1. Is my code thread safe? If not, how do I make it thread safe?


    2. Is there a way to make the interface a bit cleaner for use? Right now # define feels a bit hacky.


    3. Is there a way to avoid the use of a global unique_ptr?


    4. Should I just make it a header only library? Is there any benefits in doing so?



    .hpp:



    #pragma once

    /*
    Use it by including this header in every file required, and in your main function start a new log.
    Logger::startLog("Log.txt");
    Use the various error levels by naming them and simply passing the info and what you want to output.
    Logger::log(ERROR, "Something went wrong.");
    */

    // For the unique pointers.
    #include <memory>
    // Filestream.
    #include <fstream>
    // String class for names and parameters passed around.
    #include <string>

    #define FATAL Logger::Level::Fatal
    #define ERROR Logger::Level::Error
    #define WARNING Logger::Level::Warning
    #define INFO Logger::Level::Info
    #define DEBUG Logger::Level::Debug

    namespace Logger {
    // Severity level enum.
    enum class Level {
    Fatal,
    Error,
    Warning,
    Info,
    Debug
    };

    // Initialize the log.
    void startLog(const std::string& filepath);

    // Log a message.
    void log(Level s, const std::string& msg);

    // Logging class.
    class Log {
    public:
    Log(const std::string& filepath);
    void addLog(Level s, const std::string& msg);
    ~Log();
    private:
    // File for logging.
    std::ofstream m_logfile;
    std::string levels[5] = {"Fatal", "Error", "Warning", "Info", "Debug"};
    };
    }


    .cpp:



    #include "Log.hpp"

    namespace Logger {
    // Global Logging Object.
    std::unique_ptr<Log> g_log;

    // Initalize our logging object.
    void startLog(const std::string& filepath) {
    g_log = std::make_unique<Log>(filepath);
    Logger::log(Level::Info, "Started logging system.");
    }

    // Method which logs.
    void log(Level s, const std::string& msg) {
    g_log->addLog(s, msg);
    }

    // Create our global logging object.
    Log::Log(const std::string& filepath) : m_logfile{} {
    m_logfile.open(filepath);
    }

    // Add a message to our log.
    void Log::addLog(Level s, const std::string& msg) {
    if (m_logfile.is_open()) {
    m_logfile << levels[static_cast<int>(s)] << ": " << msg << std::endl;
    }
    }

    Log::~Log() {
    addLog(Level::Info, "Stopped logging system.");
    m_logfile.close();
    }
    }









    share|improve this question









    New contributor




    Rietty is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.







    $endgroup$















      2












      2








      2





      $begingroup$


      I've been programming for what is a probably a little bit and made a very simple logging system for my personal projects. While it works out fairly well so far, I would like advice on how to make it perform better and stuff I can do to make it more usable in general.



      Main questions include:




      1. Is my code thread safe? If not, how do I make it thread safe?


      2. Is there a way to make the interface a bit cleaner for use? Right now # define feels a bit hacky.


      3. Is there a way to avoid the use of a global unique_ptr?


      4. Should I just make it a header only library? Is there any benefits in doing so?



      .hpp:



      #pragma once

      /*
      Use it by including this header in every file required, and in your main function start a new log.
      Logger::startLog("Log.txt");
      Use the various error levels by naming them and simply passing the info and what you want to output.
      Logger::log(ERROR, "Something went wrong.");
      */

      // For the unique pointers.
      #include <memory>
      // Filestream.
      #include <fstream>
      // String class for names and parameters passed around.
      #include <string>

      #define FATAL Logger::Level::Fatal
      #define ERROR Logger::Level::Error
      #define WARNING Logger::Level::Warning
      #define INFO Logger::Level::Info
      #define DEBUG Logger::Level::Debug

      namespace Logger {
      // Severity level enum.
      enum class Level {
      Fatal,
      Error,
      Warning,
      Info,
      Debug
      };

      // Initialize the log.
      void startLog(const std::string& filepath);

      // Log a message.
      void log(Level s, const std::string& msg);

      // Logging class.
      class Log {
      public:
      Log(const std::string& filepath);
      void addLog(Level s, const std::string& msg);
      ~Log();
      private:
      // File for logging.
      std::ofstream m_logfile;
      std::string levels[5] = {"Fatal", "Error", "Warning", "Info", "Debug"};
      };
      }


      .cpp:



      #include "Log.hpp"

      namespace Logger {
      // Global Logging Object.
      std::unique_ptr<Log> g_log;

      // Initalize our logging object.
      void startLog(const std::string& filepath) {
      g_log = std::make_unique<Log>(filepath);
      Logger::log(Level::Info, "Started logging system.");
      }

      // Method which logs.
      void log(Level s, const std::string& msg) {
      g_log->addLog(s, msg);
      }

      // Create our global logging object.
      Log::Log(const std::string& filepath) : m_logfile{} {
      m_logfile.open(filepath);
      }

      // Add a message to our log.
      void Log::addLog(Level s, const std::string& msg) {
      if (m_logfile.is_open()) {
      m_logfile << levels[static_cast<int>(s)] << ": " << msg << std::endl;
      }
      }

      Log::~Log() {
      addLog(Level::Info, "Stopped logging system.");
      m_logfile.close();
      }
      }









      share|improve this question









      New contributor




      Rietty is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.







      $endgroup$




      I've been programming for what is a probably a little bit and made a very simple logging system for my personal projects. While it works out fairly well so far, I would like advice on how to make it perform better and stuff I can do to make it more usable in general.



      Main questions include:




      1. Is my code thread safe? If not, how do I make it thread safe?


      2. Is there a way to make the interface a bit cleaner for use? Right now # define feels a bit hacky.


      3. Is there a way to avoid the use of a global unique_ptr?


      4. Should I just make it a header only library? Is there any benefits in doing so?



      .hpp:



      #pragma once

      /*
      Use it by including this header in every file required, and in your main function start a new log.
      Logger::startLog("Log.txt");
      Use the various error levels by naming them and simply passing the info and what you want to output.
      Logger::log(ERROR, "Something went wrong.");
      */

      // For the unique pointers.
      #include <memory>
      // Filestream.
      #include <fstream>
      // String class for names and parameters passed around.
      #include <string>

      #define FATAL Logger::Level::Fatal
      #define ERROR Logger::Level::Error
      #define WARNING Logger::Level::Warning
      #define INFO Logger::Level::Info
      #define DEBUG Logger::Level::Debug

      namespace Logger {
      // Severity level enum.
      enum class Level {
      Fatal,
      Error,
      Warning,
      Info,
      Debug
      };

      // Initialize the log.
      void startLog(const std::string& filepath);

      // Log a message.
      void log(Level s, const std::string& msg);

      // Logging class.
      class Log {
      public:
      Log(const std::string& filepath);
      void addLog(Level s, const std::string& msg);
      ~Log();
      private:
      // File for logging.
      std::ofstream m_logfile;
      std::string levels[5] = {"Fatal", "Error", "Warning", "Info", "Debug"};
      };
      }


      .cpp:



      #include "Log.hpp"

      namespace Logger {
      // Global Logging Object.
      std::unique_ptr<Log> g_log;

      // Initalize our logging object.
      void startLog(const std::string& filepath) {
      g_log = std::make_unique<Log>(filepath);
      Logger::log(Level::Info, "Started logging system.");
      }

      // Method which logs.
      void log(Level s, const std::string& msg) {
      g_log->addLog(s, msg);
      }

      // Create our global logging object.
      Log::Log(const std::string& filepath) : m_logfile{} {
      m_logfile.open(filepath);
      }

      // Add a message to our log.
      void Log::addLog(Level s, const std::string& msg) {
      if (m_logfile.is_open()) {
      m_logfile << levels[static_cast<int>(s)] << ": " << msg << std::endl;
      }
      }

      Log::~Log() {
      addLog(Level::Info, "Stopped logging system.");
      m_logfile.close();
      }
      }






      c++ c++17






      share|improve this question









      New contributor




      Rietty is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      Rietty is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited 1 hour ago









      Jamal

      30.3k11116226




      30.3k11116226






      New contributor




      Rietty is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 7 hours ago









      RiettyRietty

      112




      112




      New contributor




      Rietty is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Rietty is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Rietty is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






















          2 Answers
          2






          active

          oldest

          votes


















          3












          $begingroup$



          1. 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.





          1. Is there a way to make the interface a bit cleaner for use? Right now #define feels 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.







          1. 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);
          }






          1. 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.)






          share|improve this answer









          $endgroup$





















            0












            $begingroup$

            A couple of things. You can avoid the #defines with a using directive . You don't need to give the caller any knowledge of the Log class. It does not need to be in the header at all. What happens if I call start log more than once? There's no protection against that. Also, I know it probably works as is, but the static cast in add log scares me because you never defined an integer value for the enum class. It seems to be begging for a segfault.



            Beyond that, how to improve the interface depends in what you want. Currently the code is not thread safe. You could use lock guards in your methods to accomplish this.



            Do you want to have one central log? Or do you want each instantiation of the log to be isolated?



            If you want one central, consider the singleton pattern and give out shared or weak pointers via a static factory, and make the ctor private. Then instead of having the function interface, you can keep a shared pointer to the logging object and give it references to it, people can then call the functions on the class.



            If you want each installation of the log to be separate, just have the user construct a log class.






            share|improve this answer








            New contributor




            Marc Olberding is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
            Check out our Code of Conduct.






            $endgroup$













            • $begingroup$
              Welcome to Code Review. You didn't use any <code>yourcode</code> tags (with Markdown: `yourcode`), so you might be interested in the formatting section of our help center.
              $endgroup$
              – Zeta
              50 mins ago













            Your Answer





            StackExchange.ifUsing("editor", function () {
            return StackExchange.using("mathjaxEditing", function () {
            StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
            StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
            });
            });
            }, "mathjax-editing");

            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "196"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });






            Rietty is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f211957%2fimplementing-a-logging-system-in-c17%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            3












            $begingroup$



            1. 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.





            1. Is there a way to make the interface a bit cleaner for use? Right now #define feels 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.







            1. 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);
            }






            1. 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.)






            share|improve this answer









            $endgroup$


















              3












              $begingroup$



              1. 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.





              1. Is there a way to make the interface a bit cleaner for use? Right now #define feels 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.







              1. 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);
              }






              1. 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.)






              share|improve this answer









              $endgroup$
















                3












                3








                3





                $begingroup$



                1. 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.





                1. Is there a way to make the interface a bit cleaner for use? Right now #define feels 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.







                1. 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);
                }






                1. 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.)






                share|improve this answer









                $endgroup$





                1. 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.





                1. Is there a way to make the interface a bit cleaner for use? Right now #define feels 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.







                1. 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);
                }






                1. 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.)







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 3 hours ago









                QuuxplusoneQuuxplusone

                12k12061




                12k12061

























                    0












                    $begingroup$

                    A couple of things. You can avoid the #defines with a using directive . You don't need to give the caller any knowledge of the Log class. It does not need to be in the header at all. What happens if I call start log more than once? There's no protection against that. Also, I know it probably works as is, but the static cast in add log scares me because you never defined an integer value for the enum class. It seems to be begging for a segfault.



                    Beyond that, how to improve the interface depends in what you want. Currently the code is not thread safe. You could use lock guards in your methods to accomplish this.



                    Do you want to have one central log? Or do you want each instantiation of the log to be isolated?



                    If you want one central, consider the singleton pattern and give out shared or weak pointers via a static factory, and make the ctor private. Then instead of having the function interface, you can keep a shared pointer to the logging object and give it references to it, people can then call the functions on the class.



                    If you want each installation of the log to be separate, just have the user construct a log class.






                    share|improve this answer








                    New contributor




                    Marc Olberding is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.






                    $endgroup$













                    • $begingroup$
                      Welcome to Code Review. You didn't use any <code>yourcode</code> tags (with Markdown: `yourcode`), so you might be interested in the formatting section of our help center.
                      $endgroup$
                      – Zeta
                      50 mins ago


















                    0












                    $begingroup$

                    A couple of things. You can avoid the #defines with a using directive . You don't need to give the caller any knowledge of the Log class. It does not need to be in the header at all. What happens if I call start log more than once? There's no protection against that. Also, I know it probably works as is, but the static cast in add log scares me because you never defined an integer value for the enum class. It seems to be begging for a segfault.



                    Beyond that, how to improve the interface depends in what you want. Currently the code is not thread safe. You could use lock guards in your methods to accomplish this.



                    Do you want to have one central log? Or do you want each instantiation of the log to be isolated?



                    If you want one central, consider the singleton pattern and give out shared or weak pointers via a static factory, and make the ctor private. Then instead of having the function interface, you can keep a shared pointer to the logging object and give it references to it, people can then call the functions on the class.



                    If you want each installation of the log to be separate, just have the user construct a log class.






                    share|improve this answer








                    New contributor




                    Marc Olberding is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.






                    $endgroup$













                    • $begingroup$
                      Welcome to Code Review. You didn't use any <code>yourcode</code> tags (with Markdown: `yourcode`), so you might be interested in the formatting section of our help center.
                      $endgroup$
                      – Zeta
                      50 mins ago
















                    0












                    0








                    0





                    $begingroup$

                    A couple of things. You can avoid the #defines with a using directive . You don't need to give the caller any knowledge of the Log class. It does not need to be in the header at all. What happens if I call start log more than once? There's no protection against that. Also, I know it probably works as is, but the static cast in add log scares me because you never defined an integer value for the enum class. It seems to be begging for a segfault.



                    Beyond that, how to improve the interface depends in what you want. Currently the code is not thread safe. You could use lock guards in your methods to accomplish this.



                    Do you want to have one central log? Or do you want each instantiation of the log to be isolated?



                    If you want one central, consider the singleton pattern and give out shared or weak pointers via a static factory, and make the ctor private. Then instead of having the function interface, you can keep a shared pointer to the logging object and give it references to it, people can then call the functions on the class.



                    If you want each installation of the log to be separate, just have the user construct a log class.






                    share|improve this answer








                    New contributor




                    Marc Olberding is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.






                    $endgroup$



                    A couple of things. You can avoid the #defines with a using directive . You don't need to give the caller any knowledge of the Log class. It does not need to be in the header at all. What happens if I call start log more than once? There's no protection against that. Also, I know it probably works as is, but the static cast in add log scares me because you never defined an integer value for the enum class. It seems to be begging for a segfault.



                    Beyond that, how to improve the interface depends in what you want. Currently the code is not thread safe. You could use lock guards in your methods to accomplish this.



                    Do you want to have one central log? Or do you want each instantiation of the log to be isolated?



                    If you want one central, consider the singleton pattern and give out shared or weak pointers via a static factory, and make the ctor private. Then instead of having the function interface, you can keep a shared pointer to the logging object and give it references to it, people can then call the functions on the class.



                    If you want each installation of the log to be separate, just have the user construct a log class.







                    share|improve this answer








                    New contributor




                    Marc Olberding is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    share|improve this answer



                    share|improve this answer






                    New contributor




                    Marc Olberding is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.









                    answered 3 hours ago









                    Marc OlberdingMarc Olberding

                    1




                    1




                    New contributor




                    Marc Olberding is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.





                    New contributor





                    Marc Olberding is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.






                    Marc Olberding is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.












                    • $begingroup$
                      Welcome to Code Review. You didn't use any <code>yourcode</code> tags (with Markdown: `yourcode`), so you might be interested in the formatting section of our help center.
                      $endgroup$
                      – Zeta
                      50 mins ago




















                    • $begingroup$
                      Welcome to Code Review. You didn't use any <code>yourcode</code> tags (with Markdown: `yourcode`), so you might be interested in the formatting section of our help center.
                      $endgroup$
                      – Zeta
                      50 mins ago


















                    $begingroup$
                    Welcome to Code Review. You didn't use any <code>yourcode</code> tags (with Markdown: `yourcode`), so you might be interested in the formatting section of our help center.
                    $endgroup$
                    – Zeta
                    50 mins ago






                    $begingroup$
                    Welcome to Code Review. You didn't use any <code>yourcode</code> tags (with Markdown: `yourcode`), so you might be interested in the formatting section of our help center.
                    $endgroup$
                    – Zeta
                    50 mins ago












                    Rietty is a new contributor. Be nice, and check out our Code of Conduct.










                    draft saved

                    draft discarded


















                    Rietty is a new contributor. Be nice, and check out our Code of Conduct.













                    Rietty is a new contributor. Be nice, and check out our Code of Conduct.












                    Rietty is a new contributor. Be nice, and check out our Code of Conduct.
















                    Thanks for contributing an answer to Code Review Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    Use MathJax to format equations. MathJax reference.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f211957%2fimplementing-a-logging-system-in-c17%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    GameSpot

                    日野市

                    Tu-95轟炸機