<div class="gmail_quote">On Mon, Jun 25, 2012 at 9:52 AM, Philippe Canal <span dir="ltr"><<a href="mailto:pcanal@fnal.gov" target="_blank">pcanal@fnal.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the context of ROOT (<<a href="http://root.cern.ch" target="_blank">http://root.cern.ch</a>>), it's automated I/O of C++<br>
objects, and of the cling Interpreter (<<a href="http://root.cern.ch/drupal/content/cling" target="_blank">http://root.cern.ch/drupal/<u></u>content/cling</a>>,<br>
we are strongly hindered by the fact that template instantiations that have<br>
a typedef as template parameter 'forget' about it in the AST (at least<br>
as far as the data members and member functions of the template instance<br>
are concerned).<br></blockquote><div>[...]</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In addition to our use case, having access to this type<br>
of information could be useful for a document generator<br>
or to clarify/simplify some error messages.   For example:<br>
<br>
   // start of stringError.C<br>
   #include <string><br>
   #include <vector><br>
   void test ()<br>
   {<br>
      std::vector<std::string> vec;<br>
      vec.push_back("abc");<br>
      vec.push_back(1.3);<br>
   }<br>
   // end of stringError.C<br>
<br>
when compiled with clang, the output currently contains the error message:<br>
<br>
stringError.C:8:18: error: reference to type 'const value_type' (aka 'const std::basic_string<char>') could not bind to an rvalue of type 'double'<br>
   vec.push_back(1);<br>
                 ^<br>
<br>
which would be even nicer, if reading:<br>
<br>
<br>
stringError.C:8:18: error: reference to type 'const value_type' (aka 'const std::string') could not bind to an rvalue of type 'int'<br>
   vec.push_back(1);<br>
                 ^<br>
<br>
where 'std::basic_string<char>' has been replaced by 'std::string'.<br></blockquote><div><br></div><div>Yes, this is a real problem which is affecting more people than just you. IIRC, there are several bugs in bugzilla with this as the root cause (see for instance <a href="http://llvm.org/PR12853">llvm.org/PR12853</a>).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In first approximation, one plausible step could be to generate a distinct<br>
template instantiations for each of the cases with distinct typedef<br>
as a template argument and a template instantiation for the case<br>
without typedef as a template argument (i.e. the primary template<br>
instantiation).   And then make sure that for the rest of the semantic<br>
analysis vector<Double32_t> and vector<double> are<br>
treated as equivalent/interchangeable/<u></u>aliases.<br></blockquote><div><br></div><div>I do not think this is the right approach: it could be extremely expensive to perform all the redundant template instantiations for canonically-equivalent-but-not-identical template arguments, and would significantly complicate the AST to have multiple definitions for the same declaration.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any ideas/thoughts on if and how being able to access the intended<br>
type of a template instantiation's members whose type depends on the<br>
template parameter(s) could be supported in any way?</blockquote><div><br></div><div>I think we should address this by adding type sugar for references to instantiated entities. For instance, in this case:</div><div><br>
</div><div>  template<typename U> struct T { template<typename V> decltype(U()+V()) get(V); };</div><div>  T<IntTypedef> x;</div><div>  FloatTypedef d;</div><div>  int a = x.get(d);</div><div><br></div><div>
... we can track that the type of 'get' is equivalent to substituting U=IntTypedef, V=FloatTypedef into the type in the primary template, and then instantiate (and cache) the type of that member. That should be significantly cheaper (and simpler) than instantiating the declaration, and would provide the same benefits.</div>
</div>