Re: [libgpiod] cxx bindings: time_point vs duration

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Wed, Oct 21, 2020 at 3:57 PM Jack Winch <sunt.un.morcov@xxxxxxxxx> wrote:
>
> 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.
>

Yes, I am aware of this. We broke ABI in the core library once already
- this is why libgpiod API version v1.6.0 has ABI version 2.2.1. I
personally care a lot more about API compatibility than ABI - I'm
mostly using libgpiod on bespoke embedded distros, built from scratch.
I know this is important for desktop distros though so I try to avoid
it whenever possible. This time however we'll be breaking both API and
ABI, so that's not an issue - it really is a major release.

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

Yes, please. I'd love to learn what the alternative for C++ is then.

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

Maybe a time_point returning helper in this case?

Bartosz