title: Where does nullptr_t reside?
body: <p>A bit of prehistory.</p>
  
  <p>I've been writing a game engine for quite some time. It's divided into several static libraries, like "utils", "rsbin" (resource system), "window", which are then linked into a single executable.</p>
  
  <p>It is a crossplatform engine, being compiled for Windows and for Android.
  Under Windows, I compile it with MinGW. Under Android, with CCTools, which is an interface to native gcc.</p>
  
  <p>One of the base classes is <code>utils::RefObject</code>, which represents a concept similar to Windows's IUnknown: it provides a reference counter to determine its lifetime and a method for querying a specific interface from base class pointer. There's also <code>template&lt; typename T &gt; utils::Ref</code>, designed specifically for this kind of objects. It holds an <code>std::atomic&lt; utils::RefObject* &gt;</code> and automatically updates its object's refcount upon construction, assignment and destruction, analogously to <code>std::shared_ptr</code>. It also allows to implicitly convert RefObjects of different types through their querying methods. Though, it's inefficient to query an object for its own type, so, <code>utils::Ref</code> overloads most of its operators, e. g. there's specific <code>utils::Ref&lt; T &gt;::Ref( T* ptr )</code> constructor, which simply increments the passed object's refcount, and general <code>utils::Ref&lt; T &gt;::Ref( RefObject* ptr )</code>, which queries its argument for instance of T and throws an exception on failure (don't worry, though, there's of course a method for the soft cast).</p>
  
  <p>But having just these two methods introduces a problem: you cannot explicitly initialize <code>utils::Ref</code> with a null pointer, as it is ambiguous; so there's also <code>utils::Ref&lt; T &gt;::Ref( nullptr_t )</code> to provide a way to do it.</p>
  
  <p>Now, we are getting to the problem at hand. In the header file, the prototype is spelled exactly as above, without any preceding <code>std::</code>. Note that I don't use <code>using namespace</code> either. For a long time, this worked.</p>
  
  <p>Now, I'm working on a graphics system. It existed before, but it was rather rudimentary, so I didn't even noticed that &lt;gl.h&gt; actually defines only OpenGL 1.1, while for newer versions you should go through &lt;glext.h&gt;. Now, it became necessary to use the latter. But including it broke the old reference class.</p>
  
  <p>Judging from error messages, MinGW now has problems with that <code>nullptr_t</code> in prototypes. I've done a quick search on the Web and found that <em>often</em> it's referred to as <code>std::nullptr_t</code>. Though, not everywhere.</p>
  
  <p><strong>Quick sumup: I had <code>nullptr_t</code> without either <code>std::</code> or <code>using namespace</code> compiling fine until I included &lt;glext.h&gt; before the header.</strong></p>
  
  <p>The site I've been using so far, cplusplus.com/reference, suggests that global <code>::nullptr_t</code> <a href="http://www.cplusplus.com/reference/cstddef/nullptr_t/" rel="nofollow">is exactly how it should be</a>. On the other hand, en.cppreference.com wiki <a href="http://en.cppreference.com/w/cpp/types/nullptr_t" rel="nofollow">tells that</a> it's actually <code>std::nullptr_t</code>.</p>
  
  <p>A quick test program, a helloworld with <code>void foo( int )</code> and <code>void foo( nullptr_t )</code>, failed to compile and the reason now is explicit <code>"error: 'nullptr_t' was not declared in this scope"</code> with suggestion to use <code>std::nullptr_t</code> instead.</p>
  
  <p>It won't be hard to add <code>std::</code> where needed; but this case left me rather curious.</p>
  
  <p>cplusplus.com was actually lying? => Answered in commets, yes. It's an inaccurate source.</p>
  
  <p>Then, if <code>nullptr_t</code> actually resides in <code>namespace std</code>, why did <code>utils::Ref</code> compile? => With suggestions in comments, ran a couple of test and discovered that &lt;mutex&gt;, included in some other header, when placed before any stddef header, defines global <code>::nullptr_t</code>. Certainly not an ideal behavior, but it's not a major bug. Probably should report it to MinGW/GCC developers anyway.</p>
  
  <p>Why inclusion of &lt;glext.h&gt; breaks it? => When any stddef header is included before &lt;mutex&gt;, the type is defined according to the standard, as <code>std::nullptr_t</code>. &lt;glext.h&gt; includes &lt;windows.h&gt;, which, in turn, certainly includes the stddef header, among with a whole pack of others which are needed for WinAPI.</p>
  
  <p>Here are the sources, defining the class in question:</p>
  
  <ul>
  <li><a href="http://pastebin.com/8ydpP9Aw" rel="nofollow">utils/ref.hpp</a></li>
  <li><a href="http://pastebin.com/KwSRyDTk" rel="nofollow">utils/ref.cpp</a></li>
  <li><a href="http://pastebin.com/7UELQxqz" rel="nofollow">utils/refobject.hpp</a></li>
  <li><a href="http://pastebin.com/qu1VTiuu" rel="nofollow">utils/refobject.cpp</a></li>
  <li><a href="http://pastebin.com/sGa23tB2" rel="nofollow">utils/logger.hpp</a> => This one uses a mutex to avoid line tearing during output.</li>
  <li><a href="http://pastebin.com/40upGeer" rel="nofollow">utils/cbase.hpp</a></li>
  </ul>
  
  <p>(the latter 2 are included and so may affect too)</p>
  
  <p>As suggested in the comments, I ran g++ -E on a test case which compiled, and found a quite interesting bit in &lt;stddef.h&gt;:</p>
  
  <pre><code>#if defined(__cplusplus) &amp;&amp; __cplusplus &gt;= 201103L
  #ifndef _GXX_NULLPTR_T
  #define _GXX_NULLPTR_T
    typedef decltype(nullptr) nullptr_t;
  #endif
  #endif /* C++11.  */
  </code></pre>
  
  <p>Now to find where <code>_GXX_NULLPTR_T</code> is defined else... a quick GREP through MinGW's files didn't find anything besides this stddef.h</p>
  
  <p>So, it's still a mystery why and how it's getting disabled. Especially when including just &lt;stddef.h&gt; and nothing else does not define <code>nullptr_t</code> anywhere, despite the bit above.</p>