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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux