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

[Chris Lattner]

On May 11, 2010, at 9:53 PM, David Greene wrote:
> The best technical interview question I've ever been asked is, "what code
> would you never write?"  Standard library functionality is at the top of my
> list.  Why would anyone replace rigorously tested code with something
> not as widely tested that one has to maintain oneself?

Because you think that the end result will be better than what you get if you don't do the work?  By the same argument, why implement a new compiler if you already have one?  The old compiler is well tested and you don't have to maintain it.  Perhaps if you were a library developer instead of a compiler developer you'd understand the opportunity and value. :)

> Again, I'm not dismissing libc++.  I'm making a general point about
> reusing hardened code.  If libc++ is demonstrably better than other
> solutions, I'll be the first on board.  But I do wonder why libstdc++ could
> not be improved in the same way while retaining is enormous testing base.

You obviously took a lot of time to familiarize yourself with the testing framework that libc++ includes?

> And what about libstdc++ doesn't work for Apple applications?

There are many many things about it that are "less than great".  Please familiarize yourself with *either* of the libstdc++ or libc++ implementations before you claim that libstdc++ can't be improved on.

And yes, there is a threshold where starting over is much easier and gives a better result than incrementally improving an existing code base.  One thing that is difficult to achieve with incremental improvement is a replacement of the community built around the codebase.

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).  Lets discuss the present and future of libc++ instead.

-Chris