Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I'm copying over from a comment i made to <a href="https://stackoverflow.com/questions/385556/how-does-c-pick-which-overloaded-function-to-call/394742#394742">answer this comment</a> at another place.</p> <blockquote> <p>You can down-cast with <code>static_cast</code>. Not so with <code>implicit_cast</code>. <code>static_cast</code> basically allows you to do any implicit conversion, and in addition the reverse of any implicit conversion (up to some limits. you can't downcast if there is a virtual base-class involved). But <code>implicit_cast</code> will <em>only</em> accept implicit conversions. no down-cast, no <code>void*-&gt;T*</code>, no <code>U-&gt;T</code> if T has only explicit constructors for U.</p> </blockquote> <p>Note that it's important to note the difference between a cast and a conversion. In the following no cast is going on</p> <pre><code>int a = 3.4; </code></pre> <p>But an implicit conversion happens from double to int. Things like an "implicit cast" don't exist, since a cast is always an explicit conversion request. The name construct for <code>boost::implicit_cast</code> is a lovely combination of "cast using implicit conversions". Now the whole implementation of <code>boost::implicit_cast</code> is this (explained <a href="https://stackoverflow.com/questions/862858/what-other-useful-casts-can-be-used-in-c/863761#863761">here</a>):</p> <pre><code>template&lt;typename T&gt; struct identity { typedef T type; }; template&lt;typename Dst&gt; Dst implicit_cast(typename identity&lt;Dst&gt;::type t) { return t; } </code></pre> <p>The idea is to use a non-deduced context for the parameter <code>t</code>. That will avoid pitfalls like the following:</p> <pre><code>call_const_version(implicit_cast(this)); // oops, wrong! </code></pre> <p>What was desired is to write it out like this</p> <pre><code>call_const_version(implicit_cast&lt;MyClass const*&gt;(this)); // right! </code></pre> <p>The compiler can't deduce what type the template parameter <code>Dst</code> should name, because it first must know what <code>identity&lt;Dst&gt;</code> is, since it is part of the parameter used for deduction. But it in turn depends on the parameter <code>Dst</code> (<code>identity</code> could be explicitly specialized for some types). Now, we got a circular dependency, for which the Standard just says such a parameter is a non-deduced context, and an explicit template-argument must be provided. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload