<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
<title></title>
<style type="text/css">
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
</style>
</head>
<body>
<p>Hi again,</p>
<p>I now realize that the email I sent earlier suffers from a few unfortunate typos, but not only that; what I wrote about your helpers (accepting a custom deleter) is extremely vague.</p>
<p>Sorry about that. I hope the added comments in this email will make it easier to understand what I meant and mean.</p>
<p>Best Regards,<br />
F</p>
<p>On 2018-07-12 23:17, Filip Roséen wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Helpers are always nice, but one immediate reaction to the patch is
that these four, as a consequence will force modules written in `C++`
to be compiled as at least `C++11`, something we formerly did not
demand.</code></pre>
</blockquote>
<p>The above was meant to be read as <em>“Helpers are nice, but an unfortunate consequence of putting them in <code>vlc_common.h</code> is that the C++ compiler used to build a module then must support (and enable) <em>c++11</em>, even if the implementation of said module does not mandate it.”</em></p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> This could be circumvented by introducing `#if __cplusplus >= 201103`
so that we do not force an error diagnostic down someones throat who
are for whatever stuck with an older compiler. One could argue that we</code></pre>
</blockquote>
<p><em>“Who are, for whatever <strong>reason</strong>, stuck…”</em></p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> As far as I am aware, both of the above overloads with custom
releasers are doing more than they are required in terms of
`noexcept`. If `Releaser` in `std::unique_ptr<class T, class Releaser>`
is not an *lvalue-reference*, it shall not throw an exception in its
*move-* and/or *copy-constructor* (which one depends on the reference
type of `r`).</code></pre>
</blockquote>
<p>The usage of <em>“shall”</em> in the above can be very misleading, at least I fear it might. I should have explained that constructing a <code>std::unique_ptr<T, U>( expr1, expr2 )</code> where <code>U</code> is not an <em>lvalue</em> type is <em>UB</em> if;</p>
<ul>
<li>the result of <em>expr2</em> is an <em>lvalue</em>, and the <em>copy-constructor</em> of <code>U</code> is not <em>nothrow copy-constructible</em>, or;</li>
<li>the result of <em>expr2</em> is an <em>rvalue</em>, and the <em>move-constructor</em> of <code>U</code> is not <em>nothrow move-constructible</em>.</li>
</ul>
<p>What the above boils down to is that the expressions passed to the <code>noexcept</code> specifier of the two functions are superfluous as we are in <em>UB-land</em> if the requirements above are not met.</p>
<p>See <code>[unique.ptr.single.ctor]p9-12</code> for more information.</p>
</body>
</html>