代码之家  ›  专栏  ›  技术社区  ›  einpoklum

定义一个并不真正提供now()函数的std::chrono Clock是“合法的”吗?

  •  6
  • einpoklum  · 技术社区  · 2 月前

    我正在编写一个C++库,它处理的数据中有一些时间值,这些值不是源于库运行的系统。我想把这些值放在 std::chrono::time_point 的(将向图书馆用户公开)。

    现在,要做到这一点,我需要指定一个 Clock 类型。好吧,这应该不是问题,对吧?我可以满足所有的 requirements 我不能吗。。。嗯,不,不是真的,我有一个障碍: now() 功能。我无法提供 now() 生成我正在查看的时间点值的系统的值!我无法访问它,也许它甚至已经不存在了;它可能刚刚停止,或被重置,或完全不存在。

    这是否意味着我应该 使用 std::chrono 类型?或者我应该创建一个时钟类型 now() 函数返回一个固定的虚拟值?还是人为地增加价值?

    2 回复  |  直到 2 月前
        1
  •  5
  •   Howard Hinnant    2 月前

    C++20版本 <chrono> 包含一个时钟 有一个...,有... now() 实际上,函数中完全没有任何内容:

    struct local_t {};
    
    template<class Duration>
        using local_time  = time_point<local_t, Duration>;
    using local_seconds = local_time<seconds>;
    using local_days    = local_time<days>;
    

    local_t 一个钟,有点。它用于定义家庭 time_point s被叫 local_time .本地时间不是指特定的时间实例 直到 与a配对 time_zone .

    local_t 不符合 Cpp17Clock requirements 。但是,模板中没有要求

    template<class Clock, class Duration>
      class time_point;
    

    那个 Clock 会见 Cpp17时钟要求 .否则 local_t 不可能存在。

    那么,当你试图说:

    local_time<seconds>::clock::now();
    

    ?

    您会遇到编译时错误。这意味着您不能使用 本地时间 在电话中 sleep_until 例如,因为 睡眠_直到 要求 时间点 s clock 为了满足 Cpp17时钟要求 .

    这种对时钟要求的放宽 时间点 直到C++20才被标准化,明确是为了引入 本地时间 然而,对 时间点 在C++20之前也从未实施过。因此,从实用的角度来看,在C++20之前,您可以很好地利用这些宽松的要求。

        2
  •  1
  •   Bailey Brightman    2 月前

    编辑:现在我看到我们正在使用一个库,不,这是不合法的。我最初的回答在下面解释了原因。

    这些是标准库的期望,而不是超出该范围的某些代码。不过,应该预期的是,任何可以在自身之外使用的库代码都符合这些要求,以便使用它的人更容易使用。然而,在内部,这并不那么重要(尽管这是值得努力的事情)

    因此,除非你正在编写一个将其传递回用户(程序员)的库,否则这不是问题。

    然而,你应该研究其他可能性,确保不可能实现.now()函数,如果没有发现任何文件表明.now()没有实现,并解释原因,如果可能的话,确保在尝试使用时出现一个好的错误。

    为了更简洁地回答,这取决于上下文。如果它是内部的、可维护的、易于解释的,那么它就很好。如果它可以变成外部的,无法解释的,不可维护的,那么就不行。找一种不同的方法。