[libcamera-devel] [RFC PATCH v2 5/9] libcamera: Implement a ControlList

[Laurent Pinchart]

Hi Kieran,

On Wed, Jun 26, 2019 at 03:02:59PM +0100, Kieran Bingham wrote:
> On 26/06/2019 14:51, Laurent Pinchart wrote:
>  <snip>
> 
> >> Any ideas or suggestions on how to do these helpers nicely? Ideally I'd
> >> want the ControlList to look like a class object - but I don't think I
> >> can just extend the std::unordered_map() interface ...
> >>
> >> I'd also want a helper for the .contains() method
> >>
> >> (which is a shame, because in C++20 .contains() is available directly on
> >> the unordered_map)
> > 
> > How about keeping the ControlList class, but making it derive from the
> > container ? That would allow you to add the few helpers you need without
> > a need to proxy everything else. You also won't need to document or test
> > the proxy methods.
> 
> I sort of want to do exactly that - but too many comments online say
> "Never derive the STL containers":
> 
> https://stackoverflow.com/questions/10477839/c-inheriting-from-stdmap
> https://www.researchgate.net/post/I_really_want_to_understand_if_there_is_any_reason_why_one_should_not_inherit_from_the_stl_vector_class_in_c2
> 
> I think the reasoning is that the STL does not implement virtual
> destructors, but does this matter if I don't implement a custom destructor?

It's one of the reasons. Another one seems that the standard says not to
do so, but I believe the reasons behind it are not relevant in this
case. If the only purpose of this inheritance is to add helper methods
to the container, without adding data members, I think it should be
fine. If we have to add data members or want to override existing
methods, then we're reaching grey waters, and I wouldn't be comfortable
going there.

-- 
Regards,

Laurent Pinchart