VS11 is steady_clock, steady?

Question

I just noticed the following code in <chrono.h>, which doesn't make sense to me.

struct system_clock
{
    static const bool is_monotonic = false; // retained
    static const bool is_steady = false;
};

class steady_clock
    : public system_clock
    {   // wraps monotonic clock
public:
    static const bool is_monotonic = true;  // retained
    static const bool is_steady = true;
    };

typedef steady_clock monotonic_clock;   // retained
typedef system_clock high_resolution_clock;

How can steady_clock be steady when it simply derives from system_clock which is not steady?

Answer 1

Ignoring the code you've shown (Jerry's answer already addresses that better than I could), presumably VC++ 2012's std::steady_clock is not steady, as evidenced by multiple bug reports currently open on MS Connect regarding this very issue:

• steady_clock class and clock() function are non conformant with C++11 and C11 standards
• [C++] std::chrono::steady_clock is not steady
• (possibly related) C++ header's high_resolution_clock does not have high resolution

Answer 2

Ignoring bugs in Microsoft's implementation for the moment, having a steady clock derive from an unsteady one (or a monotonic one derive from a non-monotonic one) makes perfectly good sense in general.

This is one of those places that the typical "is-a" terminology gets in the way, and you need to really think in terms of substitution instead. In particular, the situation is not "a steady clock is not an unsteady clock, so the derivation is wrong." Rather, the situation is "a steady clock can be substituted for an unsteady clock under any circumstances, so the derivation is fine" (and likewise for is_monotonic).

Let's consider an extreme example -- having an atomic clock connected directly to your computer. It's monotonic and about as steady as you can hope to get. Assuming its output is high enough frequency (/resolution), you could use it in place of essentially any/every other clock your system might have available.

Answer 3

I actually do not agree with the "accepted answer". It is purely wrong on the Microsoft side, and can cause unrealistic expectations. The C++11 standard requires system_clock to implement to_time_t and from_time_t, but there are no such requirements for steady_clock and high_resolution_clock. It is not an "is-a" relationship, as steady_clock does not implement all required interfaces of system_clock; nor should it. Microsoft's action does not make sense to me: How can you expect a steady_clock has to_time_t while avoiding the problem of time skewing?

So, simply put, Microsoft made a mistake, and they are slow to fix it. According to Stephan T. Lavavej, he "didn't have time to fix this in 2013 RTM", and "all of the clocks need to be reimplemented, as tracked by several active bugs". See https://connect.microsoft.com/VisualStudio/feedback/details/719443/.

I guess it was not he that wrote the rubbish fake implementation in the beginning.

EDIT: I am a bit surprised that I got downvoted, even a little upset. My downvoters and disagreers, do you realize that you are rationalizing a broken implementation, which may be changed and fixed soon? Name me one real implementation that has steady_clock inherit from system_clock and is not broken....

FACT UPDATE in July 2014: As of Visual Studio 2014 CTP2, steady_clock no longer inherits from system_clock....