[libcamera-devel] [RFC v2 1/4] hack: Camera public destructor

Tomi Valkeinen tomi.valkeinen at iki.fi
Mon Nov 30 15:26:48 CET 2020


On 30/11/2020 01:27, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Fri, Nov 27, 2020 at 03:37:35PM +0200, Tomi Valkeinen wrote:
>> Not clear why we need this with pybind11...
> 
> We'll have to figure it out :-)

My guess is that pybind11 generates code to create a shared_ptr<Camera>. You need a public
destructor for that.

Ah, no, Camera constructor is private too, so that cannot be the case.

> I've been considering a while ago handling camera instances a bit
> differently, with a facade object create by libcamera (and returned a
> unique pointer), with a reference-counted (through shared_ptr) backend
> object not visible to applications. We could implement this, either in
> the libcamera core, or in the python bindings, if it helps.

What would be the benefit of that approach in libcamera core? Isn't that just re-implementing the
same feature with more complex code? Unless you want to hide something with the backend object that
can't be hidden at the moment.

I'm not sure, but we might have the same problem with unique_ptr too. If something in pybind11
requires the destructor to be visible with shared_ptr, that could also be the case with unique_ptr.

I have considered adding facades/wrappers for some classes in the py bindings, so that I could store
extra state in those objects. But it does get complex, as I need to re-use existing objects instead
of just creating a fresh one every time I get an instance from c++ side.

That's a bit different than what you're suggesting, but would also remove the use of
shared_ptr<Camera> from the bindings itself.

But if all this is just to avoid making the Camera destructor public, I have to ask if it's worth it =).

 Tomi


More information about the libcamera-devel mailing list