[libcamera-devel] [RFC PATCH 04/17] libcamera: frame_buffer: Document the FrameBuffer::Private class

[Jacopo Mondi]

Hi Laurent

On Fri, Jul 23, 2021 at 07:00:23AM +0300, Laurent Pinchart wrote:
> The FrameBuffer::Private class is exposed to pipeline handlers, and is
> thus part of the internal libcamera API. As such, it should be
> documented.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> ---
>  src/libcamera/framebuffer.cpp | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/src/libcamera/framebuffer.cpp b/src/libcamera/framebuffer.cpp
> index 48d14b31f68d..a59e93fbdf91 100644
> --- a/src/libcamera/framebuffer.cpp
> +++ b/src/libcamera/framebuffer.cpp
> @@ -100,6 +100,16 @@ LOG_DEFINE_CATEGORY(Buffer)
>   * \brief Array of per-plane metadata
>   */
>
> +/**
> + * \class FrameBuffer::Private
> + * \brief Base class for FrameBuffer private data
> + *
> + * The FrameBuffer::Private class stores all private data associated with a
> + * framebuffer. It implements the d-pointer design pattern to hide core
> + * FrameBuffer data from the public API, and exposes utility functions to
> + * pipeline handlers.

A single function, actually, but they can grow.

Anyway, that's what's interesting and a bit scary about this pattern.
It is meant to allow changes to the internal API not to be reflected
on the public one, but it also create a 'private' interface available
to selected components, in our case the internal ones that have access
to the libcamera/internal headers.

Anyway...

Reviewed-by: Jacopo Mondi <jacopo at jmondi.org>

thanks
   j

> + */
> +
>  FrameBuffer::Private::Private()
>  	: request_(nullptr)
>  {
> --
> Regards,
>
> Laurent Pinchart
>