[Lldb-commits] r151071 - in /lldb/trunk: examples/interposing/darwin/fd_interposing/FDInterposing.cpp include/lldb/lldb-defines.h source/Host/macosx/Host.mm source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp tools/debugserver/source/MacOSX/MachThreadList.cpp tools/debugserver/source/MacOSX/i386/DNBArchImplI386.cpp tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp

[dawn at burble.org]

Please do not add C++11 support to LLDB.  I want to get lldb
building on Windows under MSVC and this could make that impossible.
Clang's Windows support is still not complete enough to build llvm,
clang and lldb on Windows, so we *have* to use MSVC there.

Thanks!
-Dawn

On Wed, Feb 22, 2012 at 05:55:49PM +0100, Benjamin Kramer wrote:
> 
> On 22.02.2012, at 16:51, Howard Hinnant wrote:
> 
> >> 
> >> On 21.02.2012, at 19:56, Greg Clayton wrote:
> >> 
> >>> Benjamin,
> >>> 
> >>> Please be careful when switching example code over to use C++11 as "lldb/trunk/examples/interposing/darwin/fd_interposing/FDInterposing.cpp" doesn't compile anymore. By default (in Lion at least) "std::shared_ptr" isn't part of the darwin libstdc++ library, so we still need to use the tr1 stuff.
> >>> 
> >>> I am checking without local C++ gurus on how to best fix this.
> >> 
> >> Oops, that was my mistake, checking that file in wasn't intended. I'll revert it.
> >> 
> >> This was just one little step to help switching to libc++ eventually. Sadly libc++ doesn't contain tr1 headers so we
> >> can't just flip the switch and everything works.
> > 
> > I'm going to start working on that faq real soon now! ;-)  Sorry it isn't there already.
> > 
> > The decision to not contain tr1 headers was a carefully considered one.  To do it right it would require a complete and separate tr1 implementation, and the manpower just wasn't there for that.
> > 
> > Fortunately there is an easy way to manage this transition that will auto-detect libc++, allowing your sources to switch back and forth between older std::libs and libc++ effortlessly.
> > 
> > Start with #include any C++03 header.  This is to get an identifying macro version number to tell which std::lib you're currently compiling with.  It could be <vector> or whatever you're previously using that is common to C++03 and C++11 libs.  If you're not already using such a header, don't include a big one gratuitously.  #include a small one gratuitously. ;-)
> > 
> > My favorite is:
> > 
> > #include <ciso646>  // Get std::lib version
> > 
> > The C++ committee was thoughtful enough to specify that this header does absolutely nothing! :-)  On libc++ it does almost nothing.  It will #define _LIBCPP_VERSION
> > 
> > Now your code knows what library you're compiling against, and there are a variety of techniques you can use to be compatible with libs that do or do not provide tr1/C++11:
> > 
> > #ifdef _LIBCPP_VERSION
> > // C++11
> > #  include <memory>   // for std::shared_ptr
> > #else
> > // TR1
> > #  include <tr1/memory>   // for std::tr1::shared_ptr
> > #endif
> > 
> > ...
> > 
> > #ifdef _LIBCPP_VERSION
> > // C++11
> > 
> > typedef std::shared_ptr<FDEvent> FDEventSP;
> > typedef std::shared_ptr<String> StringSP;
> > 
> > #else
> > // TR1
> > 
> > typedef std::tr1::shared_ptr<FDEvent> FDEventSP;
> > typedef std::tr1::shared_ptr<String> StringSP;
> > 
> > #endif
> > 
> > Hope this helps.
> 
> Thanks Howard, that looks like a good solution to the migration problem.
> 
> However, it's also worth considering to just switch LLDB to C++11 and libc++ completely. The c++11 support in clang is mature enough to compile libc++ and LLDB in C++11 mode. Xcode ships both so migration isn't painful at all. And we get the advantages of libc++ and c++11 (perfect forwarding!) for free.
> 
> On Linux we can expect to have at least GCC 4.4 around, which should have the required headers in its libstdc++. On BSD this would require building with clang + libstdc++, GCC 4.2 is way too old for this.
> 
> I have a set of patches that build a working C++11 LLDB with libc++ locally (mostly mechanical s/tr1::// and build system changes). I can push them upstream if that's ok with the LLDB devs.
> 
> - Ben
> 
> 
> 
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits