Re: [libgpiod][RFC PATCH] bindings: cxx: demote the line's parent chip reference to a weak_ptr

[Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>]

On Tue, Oct 20, 2020 at 8:59 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
>
> On Tue, Oct 20, 2020 at 7:57 AM Helmut Grohne <helmut.grohne@xxxxxxxxxx> wrote:
> >
> > On Mon, Oct 19, 2020 at 03:06:18PM +0200, Bartosz Golaszewski wrote:
> > > But this still forces us to do
> > >
> > >     return chip(::std::shared_ptr<::gpiod_chip>(this->_m_owner));
> > >
> > > instead of a much more elegant
> > >
> > >     return chip(this->_m_owner);
> > >
> > > in line.cpp and there's an even less elegant thing in iter.cpp. Or am
> > > I missing something?
> >
> > I confirm the behaviour you see. My intuition that the conversion would
> > happen implicitly was wrong.
> >
> > Still the sticking point is this: Your constructor should allow for most
> > flexibility to the caller and in this case that means it should consume
> > a shared_ptr by value.
> >
> > In order to make the case with a weak_ptr bearable, I suggest adding a
> > delegating constructor:
> >
> >     chip(const ::std::weak_ptr<::gpiod_chip>& chip_ptr) :
> >         chip(::std::shared_ptr<::gpiod_chip>(chip_ptr)) {}
> >
> > That way your desired way of calling should continue to work while not
> > forcing callers to convert a real shared_ptr to weak_ptr and back.
> >
> > Sorry for the confusion about this.
>
> This is a private constructor though and it's not meant to be exposed
> to callers of library interfaces. Only internal users will call it and
> they'll pass a weak_ptr to it alright. I really think it's fine the
> way it is now.
>
> Bartosz

I applied this for now in its current form as I want to start working
on the PImpl changes. We can tweak it later.

Bartosz