blocks|key|105538|text|据我所知，显式delete自由函数有两个一般原因:拒绝不需要的隐式转换，以及为用户提供更好的错误体验。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|105539|105540|拒绝不需要的隐式转换|105541|const的一个有用特性是，临时文件可以绑定到对const的引用。所以这是可行的：|105542|void+foo(const+int&+);
foo(42);+//+ok|code-block|syntax|javascript|105543|105544|现在，考虑到std::cref().The的目标是通过这个reference_wrapper传递到某个地方，所以我们需要底层引用来保持活动状态。如果我们只有这个重载：|105545|template+<class+T>
reference_wrapper<const+T>+cref(const+T&)+noexcept;|105546|然后我就可以编写std::cref(42)了。这将很好地工作，我将得到一个std::reference_wrapper<const+int>+-除了它将是一个悬空的引用。这段代码根本不可能正常工作。|105547|为了修复这个明显的bug，我们也有这个重载：|105548|template+<class+T>+void+cref(const+T&&)+=+delete;|105549|也就是说，我们显式地删除(或定义为已删除)一个重载，该重载采用任何r值。现在，在执行重载解析时，当我传入一个r值时，第二个重载是首选的，而这个重载是错误的，编译器会通知我们我们的错误(愚蠢的我，我不能做cref(42)!)而不是让我花几个小时在gdb上试图弄清楚为什么我没有对象。|105550|标准库中的其他示例包括：|105551|105552|为用户提供更好的诊断|105553|另一类示例可能是为受约束的函数提供更好的诊断。假设我有一个只对整型有意义的函数：|105554|template+<typename+T,+std::enable_if_t<std::is_integral_v<T>,+int>+=+0>
void+foo(T);|105555|我试着用非整型调用它：|105556|foo(4.2);+//+error:+no+matching+function|105557|正如所希望的那样，该操作失败了。但是你得到的错误并不是特别有意义。尤其是在有其他重载的情况下。有了Concepts，这会更好--希望如此，但不一定如此。|105558|但如果我添加反向显式删除重载：|105559|template+<typename+T,+std::enable_if_t<std::is_integral_v<T>,+int>+=+0>
void+foo(T);

template+<typename+T,+std::enable_if_t<!std::is_integral_v<T>,+int>+=+0>
void+foo(T)+=+delete;

foo(4.2);+//+error:+use+of+deleted+function|105560|这更加明确和直接。特别是如果foo的作者提供了说明为什么这很重要的注释。基本上，这仍然是SFINAE友好的，同时也提供了直接指示失败的static_assert的好处(然而，如果我们只是static_asserted，我们会得到更清晰的消息，但我们会失去SFINAE友好)。|105561|事实上，N4186的动机是使该注释成为代码本身的一部分(尽管此提议被拒绝)。那篇论文中的例子是：|105562|删除template+enable_if_t::value，simd_float>+operator%2B(simd_float，T)；template+enable_if_t+operator%2B(simd_float，T)+=删除；|105563|105564|标准库中的一个示例是用于make_unique<U[N]>的std::make_unique()。|105565|entityMap|0|LINK|mutability|MUTABLE|url|http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4186.pdf|1|https://en.cppreference.com/w/cpp/memory/unique_ptr/make_unique^0|7|6|0|0|0|0|5|O|5|0|0|0|6|B|T|H|0|0|8|D|11|X|0|0|0|2T|8|0|0|0|0|0|0|0|0|0|0|0|E|3|1V|D|2L|D|0|4|5|0|0|0|0|C|H|U|I|U|I|1|0^^$0|@$1|2|3|4|5|6|7|24|8|@$9|25|A|26|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|27|8|@]|D|@]|E|$]]|$1|G|3|H|5|6|7|28|8|@]|D|@]|E|$]]|$1|I|3|J|5|6|7|29|8|@$9|2A|A|2B|B|C]|$9|2C|A|2D|B|C]]|D|@]|E|$]]|$1|K|3|L|5|M|7|2E|8|@]|D|@]|E|$N|O]]|$1|P|3|-4|5|6|7|2F|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|2G|8|@$9|2H|A|2I|B|C]|$9|2J|A|2K|B|C]]|D|@]|E|$]]|$1|S|3|T|5|M|7|2L|8|@]|D|@]|E|$N|O]]|$1|U|3|V|5|6|7|2M|8|@$9|2N|A|2O|B|C]|$9|2P|A|2Q|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|2R|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|M|7|2S|8|@]|D|@]|E|$N|O]]|$1|10|3|11|5|6|7|2T|8|@$9|2U|A|2V|B|C]]|D|@]|E|$]]|$1|12|3|13|5|6|7|2W|8|@]|D|@]|E|$]]|$1|14|3|-4|5|6|7|2X|8|@]|D|@]|E|$]]|$1|15|3|16|5|6|7|2Y|8|@]|D|@]|E|$]]|$1|17|3|18|5|6|7|2Z|8|@]|D|@]|E|$]]|$1|19|3|1A|5|M|7|30|8|@]|D|@]|E|$N|O]]|$1|1B|3|1C|5|6|7|31|8|@]|D|@]|E|$]]|$1|1D|3|1E|5|M|7|32|8|@]|D|@]|E|$N|O]]|$1|1F|3|1G|5|6|7|33|8|@]|D|@]|E|$]]|$1|1H|3|1I|5|6|7|34|8|@]|D|@]|E|$]]|$1|1J|3|1K|5|M|7|35|8|@]|D|@]|E|$N|O]]|$1|1L|3|1M|5|6|7|36|8|@$9|37|A|38|B|C]|$9|39|A|3A|B|C]|$9|3B|A|3C|B|C]]|D|@]|E|$]]|$1|1N|3|1O|5|6|7|3D|8|@]|D|@$9|3E|A|3F|1|3G]]|E|$]]|$1|1P|3|1Q|5|6|7|3H|8|@]|D|@]|E|$]]|$1|1R|3|-4|5|6|7|3I|8|@]|D|@]|E|$]]|$1|1S|3|1T|5|6|7|3J|8|@$9|3K|A|3L|B|C]|$9|3M|A|3N|B|C]]|D|@$9|3O|A|3P|1|3Q]]|E|$]]|$1|1U|3|-4|5|6|7|3R|8|@]|D|@]|E|$]]]|1V|$1W|$5|1X|1Y|1Z|E|$20|21]]|22|$5|1X|1Y|1Z|E|$20|23]]]]

There are two general reasons that I know of to explicitly <code>delete</code> free functions: to reject undesired implicit conversions, and to provide a better error experience for users. 

<hr />

<h3>Rejecting undesired implicit conversions</h3>

One useful feature of <code>const</code> is that temporaries can bind to references to <code>const</code>. So this works:

<pre><code>void foo(const int&amp; );
foo(42); // ok
</code></pre>

That temporary <code>42</code> is bound to the reference parameter of the function, and its lifetime is tied to that reference parameter. 

Now, consider <code>std::cref()</code>.The goal is to pass through this <code>reference_wrapper</code> to somewhere, so we need the underlying reference to stay alive. If we just had this overload:

<pre><code>template &lt;class T&gt;
reference_wrapper&lt;const T&gt; cref(const T&amp;) noexcept;
</code></pre>

Then I could write <code>std::cref(42)</code>. That would work fine, I would get back a <code>std::reference_wrapper&lt;const int&gt;</code> - except it would be a dangling reference. There is no possible way for that code to ever work.

In an effort to fix that obvious bug, we have this overload as well:

<pre><code>template &lt;class T&gt; void cref(const T&amp;&amp;) = delete;
</code></pre>

That is, we are explicitly deleting (or defining as deleted) an overloading taking any rvalue. Now, when doing overload resolution, this 2nd overload is preferred when I pass in an rvalue, and that overload is ill-formed, and the compiler informs us of our bug (silly me, I can't do <code>cref(42)</code>!) instead of me having to spend a few hours with gdb trying to figure out why I don't have an object.

Other examples in the standard library are:

<ul>
<li><a href="https://en.cppreference.com/w/cpp/utility/as_const" rel="noreferrer"><code>std::as_const()</code></a></li>
<li><a href="https://en.cppreference.com/w/cpp/memory/addressof" rel="noreferrer"><code>std::addressof()</code></a></li>
<li><a href="https://en.cppreference.com/w/cpp/regex/regex_match" rel="noreferrer"><code>std::regex_match()</code></a> and <a href="https://en.cppreference.com/w/cpp/regex/regex_search" rel="noreferrer"><code>std::regex_search()</code></a> (#6 accepts lvalue strings, #7 rejects rvalue strings).</li>
</ul>

<h3>Better diagnostics for users</h3>

A different class of example might be to provide a better diagnostic for constrained functions. Let's say I have a function that is only meaningful for integral types:

<pre><code>template &lt;typename T, std::enable_if_t&lt;std::is_integral_v&lt;T&gt;, int&gt; = 0&gt;
void foo(T);
</code></pre>

And I try to invoke it with a non-integral type:

<pre><code>foo(4.2); // error: no matching function
</code></pre>

This fails, as desired. But the error you get isn't super meaningful. Especially if there's other overloads. With Concepts, this'll be better - hopefully, but not necessarily.

But if I add the converse explicitly deleted overload:

<pre><code>template &lt;typename T, std::enable_if_t&lt;std::is_integral_v&lt;T&gt;, int&gt; = 0&gt;
void foo(T);

template &lt;typename T, std::enable_if_t&lt;!std::is_integral_v&lt;T&gt;, int&gt; = 0&gt;
void foo(T) = delete;

foo(4.2); // error: use of deleted function
</code></pre>

This is more explicit and direct. Especially if the author of <code>foo</code> provides a comment indicating why this is important. Basically, this is still SFINAE friendly while also giving the benefit of a <code>static_assert</code> directly indicating failure (whereas if we just <code>static_assert</code>ed, we'd get a clearer message, but we'd lose SFINAE-friendliness).

Indeed, the motivation of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4186.pdf" rel="noreferrer">N4186</a> was to make that comment part of the code itself (though this proposal was rejected). The example in that paper was:

<blockquote>
<pre><code>template &lt;typename T&gt;
enable_if_t&lt;has_compatible_vector_size&lt;simd_float, T&gt;::value, simd_float&gt;
operator+(simd_float, T);

template &lt;typename T&gt;
enable_if_t&lt;!has_compatible_vector_size&lt;simd_float, T&gt;::value, simd_float&gt;
operator+(simd_float, T) = delete;
</code></pre>
</blockquote>

An example in the standard library is <a href="https://en.cppreference.com/w/cpp/memory/unique_ptr/make_unique" rel="noreferrer"><code>std::make_unique()</code></a> for <code>make_unique&lt;U[N]&gt;</code>.

Excerpt from the Standard 20.12 [function.objects] :

<pre><code>template &lt;class T&gt; reference_wrapper&lt;T&gt; ref(T&amp;) noexcept;
template &lt;class T&gt; reference_wrapper&lt;const T&gt; cref(const T&amp;) noexcept;
template &lt;class T&gt; void ref(const T&amp;&amp;) = delete;
template &lt;class T&gt; void cref(const T&amp;&amp;) = delete;
</code></pre>

I am used to seeing <code>=delete</code> in the context of member functions. The intention is to prohibit an operation that was supplied by the compiler. For example, to make a class non-copyable or non-movable. 

In this context, however, the intention appears to be the documentation of the intent. Is this right? Are there any other cases where using a <code>=delete</code> on a non-member function is desirable, preferable or inevitable?

What is the point of using delete on a non-member function?

编译器

摘自标准20.12 function.objects：template <class T> reference_wrapper<T> ref(T&) noexcept;template <class T> reference_wrapper<const T> cref(const T&) noexcept;templa...

问在非成员函数上使用delete的意义是什么？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在非成员函数上使用delete的意义是什么？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在非成员函数上使用delete的意义是什么？
EN