chrono::duration_cast 比率乘法问题

Question

我正在编写一些必须处理 NTP 时间的代码。我决定使用 std::chrono::duration 来代表他们，我希望这能让我的时间数学更容易做。

一个NTP时间用一个无符号的64位整数表示，高32位是纪元以来的秒数，低32位是小数秒。纪元日期是 1900 年 1 月 1 日，但这与我在这里处理的问题不同，我已经知道如何处理它。对于我正在使用的示例，假设时间为 1970 年 1 月 1 日以使数学更简单。

持续时间表示很简单：std::chrono::duration<std::uint64_t, std::ratio<1, INTMAX_C(0x100000000)>>。问题出在我试图在 NTP 时间和我的系统时钟之间转换时。

在我的系统上，std::chrono::system_clock::duration 是 std::chrono::duration<int64_t, std::nano>。当我尝试使用 std::chrono::duration_cast 在这两个持续时间之间投射时，我在任一方向上都被截断了。在调试器中对此进行跟踪，我发现它与 duration_cast 实现有关，它在 libstdc++、libc++ 和 boost::chrono 中以相同的方式失败。简而言之，要从系统表示转换为 ntp 表示，它乘以 8388608/1953125 的比率，并在另一个方向上乘以相反的比率。它先乘以分子，再除以分母。数学是正确的，但初始乘法溢出 64 位表示并被截断，尽管实际转换（post-除法）仍然很容易在这些位中表示。

我可以手动进行此转换，但我的问题如下：

这是实现中的错误，还是只是一个限制？
如果有限制，我应该意识到这会是个问题吗？我没有看到任何文档似乎会导致能够猜测这行不通。
是否有一种通用的方法来实现这一点而不是同一个问题的牺牲品？
这应该报告给谁？
最后，如果 C++20 出现时，我使用带有手动策划的 to_sys 和 from_sys 函数的 NTP 时钟，我是否可以简单地使用 std::chrono::clock_cast而不必担心其他微妙的问题？

这是我用来测试这个的代码和一些示例输出：

// #define BOOST
#ifdef BOOST
#  include <boost/chrono.hpp>
#  define PREFIX boost
#else
#  include <chrono>
#  define PREFIX std
#endif
#include <cstdint>
#include <iostream>

namespace chrono = PREFIX::chrono;
using PREFIX::ratio;
using PREFIX::nano;

using ntp_dur = chrono::duration<uint64_t, ratio<1, INTMAX_C(0x100000000)>>;
using std_dur = chrono::duration<int64_t, nano>;

int main() {
  auto write = [](auto & label, auto & dur) {
    std::cout << label << ": "
              << std::dec << dur.count()
              << std::hex << " (" << dur.count() << ")" << std::endl;
  };

  auto now = chrono::system_clock::now().time_since_epoch();
  write("now", now);
  std::cout << '\n';

  std::cout << "Naive conversion to ntp and back\n";
  auto a = chrono::duration_cast<std_dur>(now);
  write("std", a);
  auto b = chrono::duration_cast<ntp_dur>(a);
  write("std -> ntp", b);
  auto c = chrono::duration_cast<std_dur>(b);
  write("ntp -> std", c);
  std::cout << '\n';

  std::cout << "Broken down conversion to ntp, naive back\n";
  write("std", a);
  auto d = chrono::duration_cast<chrono::seconds>(a);
  write("std -> sec", d);
  auto e = chrono::duration_cast<ntp_dur>(d);
  write("sec -> ntp sec", e);
  auto f = a - d;
  write("std -> std frac", f);
  auto g = chrono::duration_cast<ntp_dur>(f);
  write("std frac -> ntp frac", f);
  auto h = e + g;
  write("ntp sec + ntp frac-> ntp", h);
  auto i = chrono::duration_cast<std_dur>(h);
  write("ntp -> std", i);
  std::cout << '\n';

  std::cout << "Broken down conversion to std from ntp\n";
  write("ntp", h);
  auto j = chrono::duration_cast<chrono::seconds>(h);
  write("ntp -> sec", j);
  auto k = chrono::duration_cast<std_dur>(j);
  write("src -> std sec", j);
  auto l = h - j;
  write("ntp -> ntp frac", l);
  auto m = chrono::duration_cast<std_dur>(l);
  write("ntp frac -> std frac", m);
  auto n = k + m;
  write("std sec + std frac-> std", n);
}

示例输出：

now: 1530980834103467738 (153f22f506ab1eda)

Naive conversion to ntp and back
std: 1530980834103467738 (153f22f506ab1eda)
std -> ntp: 4519932809765 (41c60fd5225)
ntp -> std: 1052378865369 (f506ab1ed9)

Broken down conversion to ntp, naive back
std: 1530980834103467738 (153f22f506ab1eda)
std -> sec: 1530980834 (5b40e9e2)
sec -> ntp sec: 6575512612832804864 (5b40e9e200000000)
std -> std frac: 103467738 (62acada)
std frac -> ntp frac: 103467738 (62acada)
ntp sec + ntp frac-> ntp: 6575512613277195414 (5b40e9e21a7cdc96)
ntp -> std: 1052378865369 (f506ab1ed9)

Broken down conversion to std from ntp
ntp: 6575512613277195414 (5b40e9e21a7cdc96)
ntp -> sec: 1530980834 (5b40e9e2)
src -> std sec: 1530980834 (5b40e9e2)
ntp -> ntp frac: 444390550 (1a7cdc96)
ntp frac -> std frac: 103467737 (62acad9)
std sec + std frac-> std: 1530980834103467737 (153f22f506ab1ed9)

Answer 1

Is this a bug in the implementations, or just a limitation?

只是一个限制。这些实现的行为符合规范。

If a limitation, should I have realized this would be a problem? I didn't see any documentation that would seem to lead to being able to guess that this would not work.

规范在 C++ 标准的 23.17.5.7 [time.duration.cast] 中。它记录了转换算法以按照您在问题中描述的方式运行。

Is there a generic way to implement this that isn't prey to the same problem?

在处理非常精细的单位或非常大的范围时，您需要注意溢出错误的可能性。 chrono::duration_cast 旨在成为最低级别的工具，以尽可能高效地处理最常见的转换。 chrono::duration_cast 尽可能准确，尽可能完全消除除法。

然而，没有任何一种转换算法能够始终使用有限的存储空间获得任意转换的正确答案。 C++17 引入了三种基于 duration_cast 的新转换算法，旨在指导截断存在的方向：

floor  // truncate towards negative infinity
ceil   // truncate towards positive infinity
round  // truncate towards nearest, to even on tie

您可以编写自己的通用转换函数来处理诸如您描述的困难情况。这种由客户提供的转换不太可能适合一般用途。例如：

template <class DOut, class Rep, class Period>
DOut
via_double(std::chrono::duration<Rep, Period> d)
{
    using namespace std::chrono;
    using dsec = duration<long double>;
    return duration_cast<DOut>(dsec{d});
}

以上示例中客户提供的转化从 duration<long double> 退回。这不太容易溢出（尽管不能免疫），通常在计算上会更昂贵，并且会遇到精度问题（并且取决于 numeric_limits<long double>::digits）。

对我 (numeric_limits<long double>::digits == 64) 来说，1530996658751420125ns 的输入往返于 1530996658751420124ns（关闭 1ns）。可以通过使用 round 而不是 duration_cast 来改进该算法（同样以更多计算为代价）：

template <class DOut, class Rep, class Period>
DOut
via_double(std::chrono::duration<Rep, Period> d)
{
    using namespace std::chrono;
    using dsec = duration<long double>;
    return round<DOut>(dsec{d});
}

现在我的往返行程非常适合输入 1530996658751420125ns。但是，如果您的 long double 只有 53 位精度，那么即使 round 也无法提供完美的往返。

Should this be reported, and to whom?

任何人都可以按照 instructions at this link 提交针对 C++ 标准库一半的缺陷报告。这样一份报告将由 C++ 标准委员会的 LWG 小组委员会审阅。它可能会被采取行动，或者可能被宣布为 NAD（不是缺陷）。如果一个问题包含建议的措辞（关于您希望如何更改规范的详细说明），它将有更高的成功机会。

即你觉得标准应该怎么说？

Finally, if, when C++20 comes around, I use an NTP clock with manually curated to_sys and from_sys functions, will I simply be able to use std::chrono::clock_cast and not have to worry about other subtle problems?

找出答案的一种方法是对 <chrono> 扩展的 C++20 规范草案的 this existing prototype 进行试验。

chrono::duration_cast 比率乘法问题

chrono::duration_cast problems during ratio multiplication

c++

c++11

chrono

c++20