<br><br><div class="gmail_quote">On Thu, Dec 3, 2009 at 6:29 AM, Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Dec 3, 2009, at 5:24 AM, Ahmed Charles wrote:<br>
<br>
> Sorry, always end up not replying to the list:<br>
><br>
> The main issue with dealing with next this way is that people adding new uses of next will probably not be using c++0x and therefore won't know it's ambiguous and that it needs to be qualified.<br>
<br>
</div>True.  But when this code is compiled under C++0X you get an easy to diagnose, easy to fix, compile-time diagnostic (as opposed to a hard-to-find run time error).<br></blockquote><div><br>Is the runtime error you are inferring potentially due to a behavioral difference between llvm::next and std::next?<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(this is not a complete list).  Additionally when /any/ two libraries are mixed (e.g. llvm and boost), there is a large potential for name clashes even when namespaces are judiciously used.  The carefully crafted C++ library should be aware of ADL issues.  It should know when ADL is being used, and when it isn't, and use ADL purposefully, not accidentally.<br>
<div class="im"></div></blockquote><div><br>It's unfortunate that the standard isn't a bit more deliberate here, especially given that these issues are (should be) well known.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> There are also two issues with rvalue references and the STL:<br>
><br>
> 1. EquivalenceClasses, in the insert and findLeader functions, it uses map functions which have versions taking rvalue references. This results in a compiler error because the private constructor of ECValue is inaccessible. The easiest fix is to explicitly call the constructor of ECValue before the insert/find calls.<br>

<br>
</div>If I'm understanding the concern, this looks easy to fix to me by simply making the private construction explicit within the scope of the code which has access to this constructor:<br>
<br>
  iterator insert(const ElemTy &Data) {<br>
    return TheMapping.insert(ECValue(Data)).first;<br>
  }<br>
<br>
You can make this change today, and it will work with your C++03 compiler with no loss of efficiency, and arguably improved clarity. </blockquote><div><br>That is correct.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
> 2. There are numerous places where there is a std::pair of pointer types and passing 0 results in the rvalue reference constructor being called. The type of 0 is deduced to be an int and an int isn't convertable to a pointer, so it fails to compile. The fix is to use nullpte (GCC doesn't seem to have this yet) or to static_cast<T*>(0) where T is the appropriate type.<br>

<br>
</div>I anticipate a standards fix for this one.  The pair<T1, T2>::pair<U, V>(U&&, V&&) constructor should not participate in overload resolution unless U is implicitly convertible to T1 and V is implicitly convertible to T2 (easily implemented with enable_if and is_convertible).  pair is still a hotbed of controversy on the committee, but I expect it to be greatly simplified over its current form prior to ratification.<font color="#888888"><br>
</font></blockquote><div><br>There will probably be at least one vendor that will ship with this issue, so if people are interested on llvm compiling there, this would need to be addressed. <br></div></div><br>