[vlc-devel] [PATCH] vlc_common: Add C++ memory management helpers

Hugo Beauzée-Luyssen hugo at beauzee.fr
Fri Jul 13 10:54:48 CEST 2018

On Fri, Jul 13, 2018, at 10:37 AM, Filip Roséen wrote:
> Hi Hugo,
> I took the liberty of joining your two messages into one, for the
> curious this email is in-reply to:
>  - https://mailman.videolan.org/pipermail/vlc-devel/2018-July/120262.html
>  - https://mailman.videolan.org/pipermail/vlc-devel/2018-July/120261.html
> On 2018-07-13 10:12, Hugo Beauzée-Luyssen wrote:
> > That's my current plan, new file, new namespace for C++ helpers!
> > Although the issue here is that having this function non-static or in
> > a non-anonymous namespace will trigger a warning if -Wnoexcept-type is
> > enabled (which it is when using -Wall) so maybe this functions will be
> > in an anonymous namespace? Or we can disable the warning specifically,
> > which I believe would be safe since we only care about our C ABI
> > (AFAIK)
> Just put the named namespace within an anonymous namespace, internal
> linkage, and in a namespace; best of both worlds.

Well, TIL, I thought anonymous namespace were doomed to be in the global namespace (no idea why I thought that, but I surely did)

>      namespace { namespace hugos_awesome_things { ... } }
> > So if I understand correctly, the correct noexcept expression would
> > be something along the line of
> > 
> > noexcept( std::is_reference<T>::value == false ||
> > std::is_lvalue_reference<decltype(Releaser)>::value == true )
>  You can simply mark the function as `noexcept`, that's it. If there
>  is an exception from constructing the `std::unique_ptr` all bets are
>  off anyhow (as that exception from within the `noexcept` marked
>  *unique_ptr* constructors causes *undefined-behavior*).

For the noexcept constructors, sure, but AFAIU constructors taking an r-value reference to the deleter are not noexcept

> > And probably a static_assert should be added to warrant that in case
> > of a non-ref type, copy/move ctors is non-throwing?
> Yes, you could add a `static_assert` to prevent what has been
> described, but I think it is enough to simple document the fact that a
> `std::unique_ptr` will be created with the parameters passed.
> By the way, Personally I would implement the two overloads involving
> `&free` by using the custom ones; less typing!

Hm, do you mean having a default param = &free for the releaser?

> Best Regards,\
> Mr. Lazy
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

  Hugo Beauzée-Luyssen
  hugo at beauzee.fr

More information about the vlc-devel mailing list