[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/Ma

dawn at burble.org dawn at burble.org
Fri Feb 24 15:14:48 PST 2012


Whew!  :)  And yes, some subset of C++11 should be fine.

-Dawn

On Fri, Feb 24, 2012 at 12:29:03PM +0100, Benjamin Kramer wrote:
> On 24.02.2012, at 03:22, "dawn at burble.org" <dawn at burble.org> wrote:
> 
> > 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.
> 
> VC10 and VC11 support a fair amount of C++11 so this would be one of
> the smaller issues, considering the amount of unix code that in lldb
> that would be needed to be ported to win32.
> 
> However this isn't something that's very urgent, so we can wait until
> at least VC11 is released.
> 
> - Ben
> >
> > 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



More information about the lldb-commits mailing list