[cfe-dev] [LLVMdev] New libc++ LLVM Subproject

[Chris Lattner]

On May 12, 2010, at 11:43 AM, Trevor Harmon wrote:
> On May 11, 2010, at 10:26 PM, Chris Lattner wrote:
>> In any case, questioning motives is not particularly interesting or useful.  If you're not interested in contributing to libc++... then don't!  I'm not particularly interested in discussing why we didn't use libstdc++ any more than the apache libcxx, or many other alternative libraries (most of which are stale/abandoned and have serious technical problems).
> 
> I don't think anyone is "questioning" motives. Just trying to understand them. Your blog post says you're looking forward to contributions from the community, but those who cannot see the motivation for the project will be unlikely to contribute to it. A deeper discussion of libc++'s design goals/motives, and how these compare to competing projects, should encourage more people to get on board. (For example, something analogous to your ACAT 2008 slides, in which you motivated the need for a new compiler, would be nice to see.)

There are three conflated issues being discussed in this thread:

1. Technology: the goal of libc++ is simply to be the best C++ '98 and '0x Standard Library available anywhere.  Nothing less - Howard has modest goals!  Fortunately, he's "done this before", has both a passion and the ability to create a great library, and has been heavily "involved" in the C++'0x library design process (serving as chair of the C++ Library Working Group for the last several years, among other things).

2. License: Howard is currently not permitted to work on GPL3 code.  In practice, this means that any code based on libstdc++ would have to be based on libstdc++ 4.2 (or earlier).  Forks are even less popular than new projects, and being limited by the design decisions of libstdc++ was not appealing.

3. Minimizing effort: The decision to build a new library from scratch instead of extending an existing one was not made lightly, and there are many aspects that went into the decision.  Probably the easiest ones to explain are:

  a) extending a C++'98 library to support C++'0x entails almost a complete rewrite.  Since all the available non-GPL3 libraries (that we were aware of) lack C++'0x support, they would all be rewrites.  Taking the liberty of starting from scratch gave Howard the opportunity to do things "his way" and has little downside.

  b) we felt that full C++'0x support will be an ABI change, and taking advantage of this ABI change opportunity allows designing the library to follow known best practices.  For example, std::string can use the short string optimization and not use COW.  Most existing libraries (including libstdc++) are unlikely to want to break ABI compatibility.  We do seek for lib++ to coexist with libstdc++ in the same address space in specific limited scenarios (like std::exception interop).

All this said, I don't see how the decision to build a new library from scratch would influence a future contributor, or why it is relevant.  If you have specific technical questions, please start a new thread and ask about them.

-Chris