Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h1>What the Standard says</h1> <p>The standard says (18.2)</p> <blockquote> <p>nullptr_t is defined as follows:</p> <pre><code>namespace std { typedef decltype(nullptr) nullptr_t; } </code></pre> <p>The type for which nullptr_t is a synonym has the characteristics described in 3.9.1 and 4.10.</p> </blockquote> <p>Where 3.9.1 basically says it should be of the same size as <code>void*</code> and 4.10 specifies the conversion rules for <code>nullptr</code>.</p> <p><strong>Edit:</strong> 3.9.9 furthermore explicitly states that <code>nullptr_t</code> is a scalar type, which means the expected initialization rules for built-in types from 8.5 apply:</p> <ul> <li>Default-initialization (<code>nullptr_t n;</code>), which leaves the value of <code>n</code> undefined. As Johannes Schaub pointed out correctly, this compiles fine with the newest version of Clang.</li> <li>Value-initialization (<code>nullptr_t n = nullptr_t();</code>), which initializes n to 0.</li> </ul> <p>This behavior is identical to e.g. <code>int</code>, so <code>nullptr_t</code> is definitely default-constructible. The interesting question here is: What does it mean for <code>nullptr_t</code> to have undefined value? At the end of the day, there is only one meaningful possible value for <code>nullptr_t</code>, which is <code>nullptr</code>. Furthermore the type itself is only defined through the semantics of the <code>nullptr</code>literal. Do these semantics still apply for an unitialized value?</p> <h1>Why that question doesn't matter in practice</h1> <p>You don't want to declare a new variable of type <code>nullptr_t</code>. The only meaningful semantic of that type is already expressed through the <code>nullptr</code> literal, so whenever you would use your custom variable of type <code>nullptr_t</code>, you can just as well use <code>nullptr</code>.</p> <h1>What does matter in practice</h1> <p>The only exception to this comes from the fact that you can take non-type template parameters of type <code>nullptr_t</code>. For this case, it is useful to know which values can convert to <code>nullptr_t</code>, which is described in 4.10:</p> <blockquote> <p>A null pointer constant is an integral constant expression (5.19) prvalue of integer type that evaluates to zero or a prvalue of type <code>std::nullptr_t</code>. [...] A null pointer constant of integral type can be converted to a prvalue of type <code>std::nullptr_t</code>.</p> </blockquote> <p>Which basically does just what you'd expect: You can write</p> <pre><code>nullptr_t n = 0; // correct: 0 is special </code></pre> <p>but not</p> <pre><code>nullptr_t n = 42; // WRONG can't convert int to nullptr_t </code></pre> <p>Both gcc 4.6 and Clang SVN get this right.</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