Re: [libgpiod] cxx bindings: time_point vs duration

[Helmut Grohne <helmut.grohne@intenta.de>]

On Wed, Oct 21, 2020 at 03:57:34PM +0200, Jack Winch wrote:
> > I don't thing nanosecond resolution is
> > guarantueed, but maybe this is good enough and you can just use
> > steady_clock? That would certainly be most welcome by consuming client
> > code.
> 
> You are correct - nanosecond resolution is not guaranteed.  It is
> completely up to the standard library implementation.  Which is why I,
> personally, would steer away from making the proposed change to struct
> line_event .  The timestamp resolution is currently well defined in
> the existing implementation and changing this may not be desirable for
> users.  If you really want a std::time_point, then you can construct
> one from a std::duration object.  See
> https://en.cppreference.com/w/cpp/chrono/time_point/time_point.

You're arguing that a std::chrono::steady_clock::time_point is not a
good match due to its undefined ratio. That can be fixed by using a
clock with a well-defined ratio.

The key here is that while you can easily convert your duration to a
time_point, a duration is conceptually the wrong thing to use. The field
does not contain a duration, but a time_point. Using a clock would give
the user the ability to compare returned timestamps to the current time
as the underlying clock provides that functionality.

So regardless of whether steady_clock is the right clock to use here, a
duration clearly is not. If you are not satisfied with the resolution
guarantuee of steady_clock, just make your own clock. Doing so results
in a lot of type safety. For instance, if you accidentally compute a
difference between a system_clock::time_point and a gpiod timestamp,
using a duration would just work whereas a time_point would result in a
compilation failure.

Helmut