[PATCH v2 1/3] libcamera: framebuffer_allocator: Move from argument in constructor
Jacopo Mondi
jacopo.mondi at ideasonboard.com
Mon Mar 11 18:01:15 CET 2024
Hi Barnabás
On Sun, Mar 10, 2024 at 02:30:33PM +0000, Barnabás Pőcze wrote:
> The single argument, of type `std::shared_ptr<Camera>`,
> is passed by value, so it can simply be moved from in order to
> avoid calling the copy constructor.
>
> Signed-off-by: Barnabás Pőcze <pobrn at protonmail.com>
> ---
> src/libcamera/framebuffer_allocator.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/libcamera/framebuffer_allocator.cpp b/src/libcamera/framebuffer_allocator.cpp
> index 94389735..8cf45ab2 100644
> --- a/src/libcamera/framebuffer_allocator.cpp
> +++ b/src/libcamera/framebuffer_allocator.cpp
> @@ -59,7 +59,7 @@ LOG_DEFINE_CATEGORY(Allocator)
> * \param[in] camera The camera
> */
> FrameBufferAllocator::FrameBufferAllocator(std::shared_ptr<Camera> camera)
> - : camera_(camera)
> + : camera_(std::move(camera))
However, if the caller of the FrameBufferAllocator constructor uses
move() when calling the constructur, this will not increase the
shared_ptr<> reference count and this could lead to a path where the
object held by the shared_ptr<> (the camera in this case) is released
before the FrameBufferAllocator instance referencing it ?
Do yuo think it's an issue ? Applications shouldn't
FrameBufferAllocator(std::move(camera))
but is there anything preventing them from doing so ?
> {
> }
>
> --
> 2.44.0
>
>
More information about the libcamera-devel
mailing list