Re: [libgpiod] cxx bindings: time_point vs duration

[Jack Winch <sunt.un.morcov@xxxxxxxxx>]

Hello Folks,

Me again.  I'm a bit late on this discussion, but wanted to raise a
couple of points on what's been discussed here.

> As far as I can see, the chip class uses the pimpl pattern, so a chip
> practically is a reference counted pointer to the actual gpiod_chip.

This has absolutely nothing to do with the PImpl pattern.  The
Pointer-to-Implementation pattern is about separating class interface
from implementation, in order to partially alleviate the absolute
nightmare of managing ABI compatibility for shared libraries which
expose a C++ interface.

One of the questions I was going to raise on a separate thread,
Bartosz and Kent, was if you care about ABI compatibility for major
versions of the libgpiod API?  This is because, currently, almost all
changes to the C++ binding will result in an ABI breakage.

Exposing public C++ interfaces from shared libraries is never really a
good idea, even if ABI compatibility is properly managed and
considered at the forefront of each development cycle.  Granted, this
is more troublesome on that other major mainstream OS, but you still
face plenty of issues with this on GNU / Linux too.

If so desired, I can start another thread on this topic.

> 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.

Jack