[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