My questions aren't intended as an attack on anyone or on libc++. I think
they are valid questions worth discussing.
> 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
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
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.