[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

[Benjamin Kramer]

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