[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