This was compiled with g++-4.-2 -O3 (without rvalue references, which would have no effect on sorting ints anyway).
Errr, that is a pretty old version at this point.
Also this was before significant performance improvements were target
at libstdc++ *and* g++.
It seems a bit strange to compare something from today to something
that is now 3 release versions old.
I believe this std::sort implementation is better, taking a few good ideas, especially with regards already most-sorted lists. Of course the libc++ could easily be lifted out and dropped into libstdc++ with very minor mangling-related changes without breaking anything.
The container changes are more fundamental, and in particular would (obviously) break the ABI, which libstdc++ has avoided for some time, even when there are known better implementation techniques (issues in std::string, and small object allocation, occur in particular).
Chris
Errr, that is a pretty old version at this point.
Also this was before significant performance improvements were target
at libstdc++ *and* g++.
Because this is the last version of gcc "oficially" available for
darwin? Noone cares about newer gcc / libstdc++ there.
I consider this pretty strange as well 
When you are trying to make at least a reasonably fair comparison
between two sets of libraries and compilers,
you shouldn't use significantly old versions of one and the latest of
the other, and then say "see the new hotness is faster and better".
It may indeed be so, but when presented as justification, you should
take the time to do it right.
*Especially* when the likelihood of something like this getting copied
and pasted all over the web is pretty high.
--Dan
Recent versions of libstdc++ are GPLv3 + runtime exemption. Te exemption means that the license is completely irrelevant for anyone using or linking against the library, but it is still an issue when you are distributing the code.
You will note that *BSD and OS X all ship with an old version of libstdc++ for precisely this reason. About the only people happy to include GPLv3 code in the core system appear to be GNU/Linux distributions.
While I can't speak for the original motivations in creating libc++, I am certain that it will be welcomed in the BSD community as an opportunity to replace a large blob of GPL'd code with something more permissively licensed. I imagine that other BSD licensed systems that depend heavily on C++, such as ReactOS and Haiku, will also be enthusiastic.
If you are not distributing a C++ standard library, then the license is not relevant to you. If you are only targeting GNU/Linux and / or Windows, then the widespread availability of a permissively licensed C++ standard library is not important to you.
In either of these cases, as Chris says, you are completely free to ignore the existence of libc++, just as people who are happy with GCC are free to ignore the existence of clang. On behalf of everyone who isn't so fortunate, I'd like to thank Howard and everyone else who has and will work on libc++.
David
-- Sent from my Apple II
How so? What's the issue? What additional restrictions are put on the
distributor? If you ship libstdc++ you have to include the source code,
whether it's GPLv2 or GPLv3. Is it the anti-Tivoization thing that's a
problem? I could see that being an issue for things like the iPhone.
Just trying to understand the implications...
-Dave
It doesn't really matter. It is widely known that Apple employees are generally not allowed to touch GPL3 code. The reasons and decision was not an engineering choice.
-Chris
You can find the FreeBSD Foundation's position here:
http://www.freebsdfoundation.org/press/2007Aug-newsletter.shtml
OpenBSD has a simpler view, that any license that contains multiple pages of legalese restricts the users' freedoms too much.
NetBSD, as far as I know, has no strict policy towards GPLv3, but is working to eliminate all GPL'd code (v2 or v3) from the base system.
David
Understood. And license issues are as good a reason as any to start
something new. Thanks for helping me understand.
-Dave
Thanks for the link. I'm working on my own private project that I
hope to put out there in the not-to-distant future and documents
like this help me make a more informed license choice.
-Dave
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.)
Trevor
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
Elsewhere in this thread Howard explained that his plans for the debug
mode entail "significant debug functionality curtailment", which frankly
makes the project sound quite a bit less ambitious than you describe
(and is one reason why I'm personally having a hard time becoming
excited about libc++ as a potential replacement for libstdc++).
That is not set in stone at this point. An "abi-versioned" debug mode is another possibility. Right now filling in more missing functionality is on my front burner.
-Howard
the goal of libc++ is simply to be the best C++ '98 and '0x Standard Library available anywhere. Nothing less - Howard has modest goals!
Elsewhere in this thread Howard explained that his plans for the debug
mode entail "significant debug functionality curtailment", which frankly
makes the project sound quite a bit less ambitious than you describe
(and is one reason why I'm personally having a hard time becoming
excited about libc++ as a potential replacement for libstdc++).That is not set in stone at this point.
Ah, I'm very glad to hear it!
An "abi-versioned" debug mode is another possibility.
Sounds intriguing.
Right now filling in more missing functionality is on my front burner.
I completely understand, and agree it's a much higher priority.
Thanks again for the reassurance.
That is not set in stone at this point.
Ah, I’m very glad to hear it!
An “abi-versioned” debug mode is another possibility.
Sounds intriguing.
VC2010 has pragma detect_mismatch for issues like this: http://msdn.microsoft.com/en-us/library/ee956429.aspx I’m sure it wouldn’t be too hard to implement, if the entire toolchain is LLVM.
I’m also curious as to why major versions of libstdc++ and libc++ (in the future) would require ABI compatibility? Considering that MS breaks ABI compatibility with each version, is there anything about the users of other toolchains that make ABI compatibility a greater concern? My impression of FOSS has always been that compatibility is an easier issue because the source for most things is always available. Perhaps having a consistent ABI versioning story for libc++ is something that should be looked into?
Consider someone who has boost ( a large C++ library) installed on their linux / mac box.
The standard library which boost was compiled against must be ABI compatible with the version used in every application using boost. Updates require either supporting multiple ABI-incompatible versions of the boost library and headers at the same time, or having a single "break the world", where every application is recompiled at the same time. I've had to do that before and it is very painful.
Windows has tried harder to make this kind of thing work in the past, linux and mac less so.
A fundamentally different approach to libraries, other than just dumping the boost headers in /usr/local/include/boost and the library in /usr/local/lib would be required to make this work.
Chris
That is why for all of my libraries, I use postfixes on the library
name, as Boost does (although mine are extended to include more then
Boost does. Perhaps such a convention should be used here too.