Início / coding / Perguntas / 79452156
Accepted
einpoklum
Asked: 2025-02-20 00:48:22 +0800 CST

É "legítimo" definir um std::chrono Clock que não oferece realmente uma função now()?

  • 772

Estou escrevendo uma biblioteca C++, que trabalha com dados que têm alguns valores de tempo neles - valores que não se originam no sistema em que a biblioteca é executada. Quero colocar esses valores em std::chrono::time_point's (que serão expostos aos usuários da biblioteca).

Agora, para fazer isso, preciso especificar um Clocktipo. Ok, isso não deve ser um problema, certo? Posso atender a todos os requisitos de , não posso? ... hmm, não, não realmente, tenho um obstáculo: a now()função. Não posso fornecer um now()valor para o sistema onde os valores de ponto de tempo que estou olhando foram gerados! Não tenho acesso a ele, e talvez ele nem exista mais; e pode ter parado, ou sido reiniciado, ou deixado de existir completamente.

Isso significa que eu não devo usar std::chronotipos? Ou devo criar um tipo de relógio cuja now()função retorna um valor fictício fixo? Ou um valor artificialmente crescente?

c++

2 respostas

  1. Best Answer

    A versão C++20 <chrono>contém um relógio que não tem uma now()função e, na verdade, não tem absolutamente nada nele:

    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 é um relógio, mais ou menos. Ele é usado para definir a família de time_points chamada local_time. Um horário local não se refere a uma instância específica no tempo até ser pareado com um time_zone.

    local_tnão atende aos requisitos do Cpp17Clock . No entanto, não há nenhum requisito no modelo

    template<class Clock, class Duration>
  class time_point;

    que Clockatendem aos requisitos do Cpp17Clock . Caso contrário, local_tnão poderia existir.

    Então o que acontece quando você tenta dizer:

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

    ?

    Você obtém um erro de tempo de compilação. Isso significa que você não pode usar local_timeem uma chamada para sleep_untilpor exemplo, porque sleep_until requer que o time_point's clockatenda aos requisitos do Cpp17Clock .

    Esse relaxamento dos requisitos de clock para time_pointnão foi padronizado até C++20, expressamente com o propósito de introduzir local_time. No entanto, os requisitos mais restritos para time_pointtambém nunca foram impostos antes de C++20. Então, de um ponto de vista prático, você está bem em aproveitar esses requisitos relaxados antes de C++20.

    • 9

  2. Editar: Agora que vejo que estamos usando uma biblioteca, não, isso não é legítimo. Minha resposta original explica o porquê abaixo.

    Essas são as expectativas da biblioteca padrão, não do código de alguém fora desse escopo. Deve-se esperar, no entanto, que qualquer código de biblioteca que possa ser usado fora de si mesmo esteja em conformidade com esses requisitos para facilitar para aqueles que o usam. Internamente, no entanto, isso é menos importante (embora, algo pelo qual se deve lutar)

    Então, a menos que você esteja escrevendo uma biblioteca que passa isso de volta para um usuário, um programador, isso não é um problema.

    No entanto, você deve analisar outras possibilidades, garantir que não seja possível implementar uma função .now(), se nenhuma for encontrada, documentar que .now() não foi implementado, juntamente com uma explicação do motivo e, se possível, garantir que um bom erro seja apresentado se seu uso for tentado.

    Para responder de forma mais concisa, depende do contexto. Se for interno, sustentável e facilmente explicável, então está tudo bem. Se puder se tornar externo, não for explicável, não for sustentável, então não. Encontre uma maneira diferente.

    • 0

relate perguntas