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

David Greene dag at cray.com
Wed May 12 06:57:51 PDT 2010


My questions aren't intended as an attack on anyone or on libc++.  I think
they are valid questions worth discussing.

On Wednesday 12 May 2010 00:26:38 Chris Lattner wrote:
> 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. :)

LLVM has several good reasons to exist: license, the gcc developers'
prior resistance to a plugin architecture, JIT functionality and so on.

I simply don't see or don't understand that libstdc++ has a similar
level of "closedness."

> > 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?

I'm not sure what you're driving at.  What does libc++'s testing framework
have to do with improving libstdc++?  Can you make the connection for me?

"Testing base" as I meant it doesn't mean testcases.  It means a huge amount
of people running the code in production environments and filing bugs.

My unfamiliarity with libc++'s testing framework isn't relevant as far as I
can see.  Seems like an ad hominem argument to me.

> > 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.

Wait.  Isn't the burden on libc++ developers to argue their case?  What about
libstdc++ prevents it from being improved?

> 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

Yes, that's true.  But I haven't yet been told why libstdc++ is at that point.

>  thing that is difficult to achieve with incremental improvement is a
>  replacement of the community built around the codebase.

Ok, so what about libstdc++'s community needs fixing?  I've found the
libstdc++ developers quite responsive and easy to work with.

> In any case, questioning motives is not particularly interesting or useful.

I think "questioning" is the wrong word.  It is always good to take a step
back and ask whether there is a better, more productive and more
beneficial path.

>   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.

Here's the sad thing about this.  We have the potential to improve libstdc++,
which is widely used.  Many, many people could benefit.  Maybe libc++ will
get that userbase eventually.  But libstdc++ has that _today_.  Without a
strong motivation for libc++, I can only conclude that improving libstdc++
is a much bigger lever that rewriting something from scratch.

You've hinted at issues with libstdc++.  I would like to understand those.
And it's not reasonable to tell people, "go study the libstdc++ code and
then come back."

The reason there are "stale/abandoned" libraries that "have serious technical 
problems" is that NIH is a strong motivator and people didn't want to improve
what is already there.  If improvement isn't possible, fine.  But I need to be
convinced of that.

                                         -Dave



More information about the cfe-dev mailing list