title: basic_ostream::operator<< char ambiguity between basic_ostream and custom class
body: <p>Consider this example:</p>
  <pre><code>#include &lt;sstream&gt;
  #include &lt;ctime&gt;
  
  using MyStream = std::stringstream;
  
  struct MyTime
  {
      explicit MyTime(std::time_t time) // w/o explicit the MyTime operator &lt;&lt; is ambigous as well
      {
      }
  };
  
  /*
  
  having this overload of course solves everything, but that seems wrong
  
  std::stringstream &amp;operator&lt;&lt;(std::stringstream &amp;stream, char c)
  {
      stream.put(c);
      return stream;
  }
  */
  
  MyStream&amp; operator&lt;&lt;(MyStream &amp;stream, std::time_t time)
  {
      return stream;
  }
  
  MyStream&amp; operator&lt;&lt;(MyStream &amp;stream, const MyTime &amp;time)
  {
      return stream;
  }
  
  int main(int argc, char **argv)
  {
      MyStream stream;
      stream &lt;&lt; 'Z';
      return 0;
  }
  </code></pre>
  <p>Without having the <code>std::stringstream &amp;operator&lt;&lt;(std::stringstream &amp;stream, char c)</code> declaration, the <code>stream &lt;&lt; 'Z'</code> fails with abmiguity (since there is no overload for <code>char</code>, it can be promoted to both short and hit <code>basic_ostream</code> and to <code>time_t</code> and hit <code>MyStream</code>). I don't really want to use <code>basic_ostream::put</code>) since the chaining of multiple writes would then look ugly (of course if that is the last resort then...). So this gives me two questions:</p>
  <ol>
  <li>What is the rationale of not having a <code>char</code> overload for <code>basic_ostream::operator&lt;&lt;</code> ? Is that all down to character encodings?</li>
  <li>Are there any nice solutions (something that I am missing apart from using <code>put</code> or having the <code>char</code> overload)?</li>
  </ol>
  <p><strong>UPDATE</strong></p>
  <p>So it seems that inheriting from <code>std::stringstream</code> vs using <code>using</code> fixes the issue, but this leaves me with the dilemma of going against the &quot;never inherit from stl classes&quot; dogma.</p>
  <p>I guess the issue arises from the fact that <code>using</code> does not actually introduce a new type, thus the ambiguity:</p>
  <blockquote>
  <p>A type alias declaration introduces a name which can be used as a synonym for the type denoted by type-id. It does not introduce a new type and it cannot change the meaning of an existing type name.</p>
  </blockquote>