Re: [boost] [system] Boost.Timer replacement

Subject: Re: [boost] [system] Boost.Timer replacement
From: Greg Rubino (bibil.thaysose_at_[hidden])
Date: 2011-09-13 11:58:22

On Tue, Sep 13, 2011 at 11:05 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
> "The best is the enemy of the good."
>
> Voltaire's famous bon mot applies to a replacement for Boost.Timer.
> I've had a "good", although not "best", replacement ready since circa
> 2006. It has always been set aside waiting for something better. The
> data-time, std::chrono, boost::chrono, boost::stopwatch, and probably
> others, were all candidates.
>
> I'm tired of waiting.
>
> http://beman.github.com/timer/ documents a useful replacement for
> Boost.Timer. The full library has been in the sandbox for years, but
> current development is on GitHub.
>
> See https://github.com/Beman/timer
>
> I'd like to move the header into boost/system/pending or
> boost/system/detail, and the rest into the appropriate libs/system
> subdirectories. The library will be proposed for a full review, or a
> mini-review if enough other Boost libraries start using it. If Endian
> gets accepted, for example, it certainly needs timing benchmarks.
>
> Comments?
>

Haven't looked through the whole lib yet, but I did just encounter
this snippet in timer .../libs/system/src/run_timer.cpp:

    for (; *format; ++format)
    {
      if (*format != '%' || !*(format+1) || !std::strchr("wustp", *(format+1)))
        os << *format;
      else
      {
        ++format;
        switch (*format)
        {
        case 'w':
          os << times.wall / sec;
          break;
        ...
        default:
          assert(0);
        }
      }
    }

It raises a couple of questions for me, which I could answer by
testing, but I don't really have time to set that up at the moment.

The first question is: if my program reaches 'assert(0);', how much
information is that going to give me about what went wrong?  Actually,
I quickly tested this and it gives me the line number and function
name, so that's not too bad.  Although I would definitely prefer to be
able to determine the cause of the assertion failure by looking at the
content of the assertion that failed, because it saves me the steps of
opening a source file and looking around.

The second question is, does this allow using a format string
consisting of a single letter from the set ("wustp") followed by a
NULL as a format string (e.g. "w\0")?  It seems like it does, but
again I haven't yet tested the code.  I'm not sure that it's a
problem, but it just stood out since it doesn't seem to fit the
intent.

That's all for now!

--Greg