Обоснованием было предоставить поставщикам немного больше свободы для steady_clock и high_resolution_clock.Оглядываясь назад, эта свобода не была необходима, поскольку на сегодняшний день во всех реализациях используются целочисленные типы со знаком.
Последствия использования беззнакового rep в этих часах состоят в том, что их вложенный тип duration не будет одним изшесть «предопределенных» длительностей:
nanoseconds
microseconds
milliseconds
seconds
minutes
hours
Поскольку они должны быть подписаны.Также клиенты часов, использующие rep без знака, должны были бы быть осторожны с вычитанием time_point s из этих часов: вычитание t0 - t1, когда t0 < t1 приведет к значению переполнения без знака: Хорошо определено, но потенциально неожиданно.
Такие часы можно безопасно использовать, и существуют случаи использования для переполнения без знака.Но это, скорее всего, в целом более подвержено ошибкам.
Причина, по которой эта широта не была расширена до system_clock, заключалась в том, что надеялись, что system_clock будет отслеживать Unix Time , и яхотел потребовать, чтобы даты до 1970-01-01 00:00:00 UTC были представлены в system_clock::time_point.system_clock - это те часы, которые должны быть связаны с человеческими календарями.
В черновой спецификации C ++ 20 окончательно будет определено отношение Unix Time , и оно будетнамного проще конвертировать между system_clock::time_point и гражданским календарем, включая даты до 1970-01-01 00:00:00 UTC.
Но steady_clock остается «секундомером»: очень хорошо для синхронизациивещи, но никак не связаны с человеческими календарями.