Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-96

Iostream-style formatting in log package

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None
    • Location:
      this issue page

      Description

      Current implementation of the log package provides two ways to format messages:

      • via sprintf-type formatting, e.g. LOG_INFO("ra = %f, decl = %f", ra, decl);
      • via boost::format-like syntax, e.g. LOGF_INFO("ra = %1%, decl = %2%" % ra % decl);

      Both of those approaches suffer from the common problem - they are not type safe which can lead to run-time crashes. It is too easy to mess format string in a ways that are hard to detect during code review and it's not always possible to unit-test every generated message produced by the code. This drawback makes developers write code like this:

          if (LOG_CHECK_DEBUG()) {
              std::ostrstream str;
              str << "ra = " << ra << ", decl = " << decl;
              LOGF_DEBUG("%1%" % str.str());
          }
      

      which is safer but both non-efficient and unnecessary.

      The proposal is to extend log interfaces to support type-safe iostream-style formatting. This can possibly be done in one of the two ways:

      • by introducing new set of macros with names like LOGS_DEBUG, LOGS_INFO, etc.
        • logging message will look like LOGS_INFO("ra = " << ra << ", decl = " << decl);
        • drawback here is that there is already large set of macros defined in Log.h, extending this set may make it harder to remember
      • by reusing existing macro names, basically creating "macro overloads", e.g. re-using LOG_INFO one could write LOG_INFO("ra = " << ra << ", decl = " << decl);
        • logic here would be: if LOG_INFO has a single argument then treat it as an expression for stream insertion, otherwise do sprintf-like formatting.
        • (I believe this can be done with not-too-complicated preprocessing magic)

      Since there are actually two proposals here, please vote for one of these options:

      • no extension necessary
      • prefer new macro names for new syntax (LOGS(), LOGS_DEBUG(), etc.)
      • prefer re-using existing macro (LOG(), LOG_DEBUG(), etc.)

      I personally prefer latter option to keep the number of macro names to remember at reasonable minimum.

        Attachments

          Container Issues

            Issue Links

              Activity

                People

                • Assignee:
                  salnikov Andy Salnikov
                  Reporter:
                  salnikov Andy Salnikov
                  Watchers:
                  Andy Salnikov, Jacek Becla, Jim Bosch, Kian-Tat Lim, Russell Owen, Steve Pietrowicz, Tim Jenness
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  7 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Planned End:

                    Summary Panel