VS11 устойчив, устойчив?

Я просто заметил следующий код в <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

Игнорирование ошибок в реализации Microsoft на данный момент, когда устойчивые часы происходят из нестационарного (или монотонного, происходящего от немонотонного), в целом имеют совершенно хороший смысл.

Это одно из тех мест, где типичная терминология "есть-а" мешает, и вам нужно действительно думать о замене вместо этого. В частности, ситуация не "устойчивые часы не являются нестационарными часами, поэтому вывод неправильный". Скорее, ситуация "постоянные часы могут быть заменены нестационарными часами при любых обстоятельствах, поэтому вывод хорош" (а также для is_monotonic).

Рассмотрим крайний пример - с атомными часами, подключенными непосредственно к вашему компьютеру. Это монотонно и примерно так же устойчиво, как вы можете надеяться. Предполагая, что его выход является достаточно высокой частотой (/разрешением), вы можете использовать его вместо практически любых/любых других часов, доступных вашей системе.

Ответ 2

Игнорируя код, который вы показали (ответ Джерри уже адресован, что лучше, чем я мог), предположительно VС++ 2012 std::steady_clock не является устойчивым, о чем свидетельствуют многочисленные отчеты об ошибках, открытые в настоящее время на MS Connect относительно этой самой проблемы:

Ответ 3

Я действительно не согласен с "принятым ответом". Это чисто неправильно на стороне Microsoft и может привести к нереалистичным ожиданиям. Для стандарта С++ 11 требуется system_clock реализовать to_time_t и from_time_t, но таких требований для steady_clock и high_resolution_clock нет. Это не отношение "is-a", так как steady_clock не реализует все необходимые интерфейсы system_clock; и не должно. Действия Microsoft для меня не имеют смысла: как вы можете ожидать, что steady_clock имеет to_time_t, избегая проблемы перекоса во времени?

Итак, попросту говоря, Microsoft допустила ошибку, и они медленно исправляют ее. По словам Стефана Т. Лававей, "у него не было времени исправить это в 2013 году RTM", и "все часы должны быть переопределены, поскольку отслеживаются несколькими активными ошибками". См. https://connect.microsoft.com/VisualStudio/feedback/details/719443/.

Я предполагаю, что он не писал, что вначале он написал фальшивую реализацию мусора.

РЕДАКТОР: Я немного удивлен, что я получил вниз, даже немного расстроенный. Мои сторонники и несогласие, понимаете ли вы, что вы рационализируете нарушенную реализацию, которая может быть изменена и исправлена ​​в ближайшее время? Назовите мне одну реальную реализацию, которая имеет steady_clock наследует от system_clock и не нарушена....

ФАКТ ОБНОВЛЕНИЯ в июле 2014 года: по состоянию на Visual CTP2 Visual Studio 2014 steady_clock больше не наследуется от system_clock....