[LLVMdev] patch for portability

Ahmed Charles ahmedcharles at gmail.com
Thu Dec 3 02:24:50 PST 2009


Sorry, always end up not replying to the list:

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.

There are also two issues with rvalue references and the STL:

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091203/91fdda1b/attachment.html>


More information about the llvm-dev mailing list