Question

我刚注意到<chrono.h>中的以下代码，这对我来说没有意义。

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;

如果steady_clock只是来源于system_clock并且不稳定，那么{{1}}如何稳定？

Answer 1

忽略你已经展示过的代码（杰里的答案已经解决了这个问题），大概VC ++ 2012的std::steady_clock ，正如MS Connect目前就此问题开放的多个错误报告所证明的那样：

Answer 2

暂时忽略微软实施中的错误，一个稳定的时钟来自一个不稳定的时钟（或一个单调来自非单调的时钟），一般来说非常有意义。

这是典型的“is-a”术语阻碍的地方之一，你需要真正考虑替代。特别是，情况不是“稳定的时钟不是一个不稳定的时钟，所以推导是错误的。”相反，情况是“在任何情况下都可以用稳定的时钟代替不稳定的时钟，因此推导很好”（同样适用于is_monotonic）。

让我们考虑一个极端的例子 - 将原子钟直接连接到您的计算机。它是单调的，并且和你希望得到的一样稳定。假设其输出频率（/分辨率）足够高，您可以使用它代替系统可能具有的任何/所有其他时钟。

Answer 3

我实际上不同意“接受的答案”。这在微软方面完全是错误的，并且可能导致不切实际的期望。 C ++ 11标准需要system_clock来实现to_time_t和from_time_t，但steady_clock和high_resolution_clock没有此类要求。它不是“is-a”关系，因为steady_clock没有实现system_clock所有必需的接口;也不应该。微软的行为对我没有意义：你如何期望steady_clock有to_time_t同时避免时间偏差的问题？

所以，简单地说，微软犯了一个错误，他们修复它的速度很慢。根据Stephan T. Lavavej的说法，他“没有时间在2013 RTM中解决这个问题”，并且“所有时钟都需要重新实现，因为有几个活动错误需要跟踪”。请参阅https://connect.microsoft.com/VisualStudio/feedback/details/719443/。

我想不是他在开始时编写了垃圾假实现。

编辑：我有点惊讶，我被投票，甚至有点不高兴。我的贬低者和分歧者，你是否意识到你正在合理化一个破碎的实施，这可能会很快改变和修复？为我命名一个真实的实现，steady_clock继承自system_clock并且没有被破坏....

2014年7月的事实更新：从 Visual Studio 2014 CTP2 开始，steady_clock不再继承自system_clock ....

VS11稳定，稳定吗？

3 个答案: