Not being a c++ dev, I didn't realize there were multiple versions of the standard library - are they just different implementations of the same api? Are there other languages with multiple implementations of the standard lib?
I would say most languages do. C is another one: the original AT&T C library has found its way via changes into some of the BSDs, but Linux systems typically use the GNU C library ("glibc"), which for copyright reasons had to be done as an independent implementation (the Unix source at the time was proprietary). Microsoft and IBM also have their own C library implementations.
Apple, Intel, HP, ... also have their own C library implementations, to say nothing of dinkumware and musl-libc and ..., or the various glibc derivatives like eglibc and bionic. I could go on for quite a while, now that I think about it.
(e)glibc and friends are fairly critical since they are the one exposing kernel features. Those that save a bit of space on embedded systems also have a selling point. For C++, aside from must-haves like open-source licences and community support, I don't see what the differentiators are.
> (e)glibc and friends are fairly critical since they are the one exposing kernel features.
By default. Unlike in Windows (from what I understand), in Unix-like OSes (Linux, the BSDs, probably others) it's entirely possible for user programs to talk directly to the kernel via a published API.
In Linux, C programs can use the syscall(2) function and x86 and x86-64 assembly language programs can use either the sysenter opcode or the int 0x80 interface, which is why linux-gate.so.1 exists and is mapped into every process: The kernel determines which method at boot and so userspace code (inclusive of libc) can't know in advance, so it uses the linux-gate.so.1 interface, instead.
Hm. Is that really that surprising? Many more mature languages have been standardized with multiple competing implementations, some proprietary, some free.
In fact, I think among popular languages, there are more of them with multiple competing implementations than there are with just one. Java, C, C++, Objective-C, C#, Fortran, JavaScript, Common Lisp, and Scheme all have multiple implementations, with their own implementations of the standard library.
The main exceptions are the collection of "scripting languages" which got popular in the late '90s and early 2000s like Perl, Python, Ruby, and PHP, which have mostly grown communities around a single implementation. But Ruby and Python at least (I'm not sure about the others, being less familiar with them) have been working towards multiple implementations and at least somewhat standardizing the core language and library to make multiple implementations more viable.
Yes and yes! So, the C++ standard library differences don't usually bite you unless you're e.g. Building executables on windows with mingw and trying to link against libraries built with visual studio that use STL features at the API, but there are indeed several implementations out there. libstdc++, libc++, and msvcrt are among the more common.
As for other languages with several standard libraries: a while ago that was a frequent criticism of D -- there were two competing standard libraries, which caused some division in the community.
It had a standard library, and a non-standard library that was more popular than the standard one, and they were not compatible at all.
The reason it caused the division at community is that the ones that you could not use both on the same project, this meant that for a while you had two "D" languages that were separate, libraries made with one did not worked with the other...
Oh man, and I'm glad they finally settled for Phobos. I don't use D much, but thanks to gdc, the gcc frontend to dmd, and Phobos, writing D actually became acceptable, almost enjoyable. There's, of course, still the fact that D is not very widely used.
Although, not all of Tango (the non-standard one) is available in D2/Phobos already. For example, Phobos has XML [2,3] stuff, but Tango's is supposed to be better [0]. Port is ongoing [1].
C++ has an ABI that almost all vendors actively work towards conformance to called the Itanium C++ ABI (yes, it applies to other architectures too):
This document was developed jointly by an informal
industry coalition consisting of (in alphabetical order)
CodeSourcery, Compaq, EDG, HP, IBM, Intel, Red Hat, and
SGI. Additional contributions were provided by a variety of
individuals.
...
In general, this document is written as a generic
specification, to be usable by C++ implementations on a
variety of architectures.
True, what many perceive as the C ABI is actually the OS ABI.
As most OSs tend to be written mostly in C, it is natural that C ABI == OS ABI.
In the few cases where the OS was written in other languages, like the mainframe systems, the early 80's OS done in Pascal dialects (Mac OS), Modula-2 (Lillith), Assembly (MS-DOS/CP-M) and many others to list here, there was no C ABI to speak of.
That isn't true. IBM and Oracle's compiler do not share a compatible ABI with g++ or clang. Oracle is adopting the common ABI in Studio 13 and that's a pretty big deal.
Back in the old days, I used to prepare for interviews by writing the implementation for the (at the time) c and then c++ standard libraries. Interviewers would often draw from the spec for whiteboard coding. Even if it differed from the spec, it really reduced my stress level.
The obvious win was that I knew the standards backward and forward, especially which ones were thread safe when that became important. It also helped with the same sort of interviews where I'd write the function prototype and then work through the implementation with the candidate.
The other huge win for me was that I ended up developing an appreciation for automated test harnesses so I could implement without bias from the control.
I'm not sure I could recommend implementing your own c++11 library (other than as an embedded subset for resource-constrained systems) but it can be fun to go through and do K&R as a bit of kata.
PyPy reuses the Python stdlib as much as possible (though they do have patched up and/or rpython versions of some modules). PyPy's advantage is performance and hackability, but the stdlib isn't critical to that.
Every JavaScript engine has its own implementation of the JS standard library. V8's, for example, is almost entirely implemented in JS itself, while SpiderMonkey's is implemented mostly in C++ (though is migrating to more self-hosted in JS).
Java, Lisp, etc. have multiple implementations too. Different implementations often have different characteristics -- performance, compliance with the standard, etc.
In the specific case of C++, standard compliance was probably a pretty major factor, as the standard library for C++ is very complex, and vendors are not necessarily always fast to keep up with new features (or willing to port these to older platforms). For quite some time, STLport <http://www.stlport.org> was a life saver for providing modern, efficiently implemented library features on not-so-modern platforms.
Conversely, the fact that the Apache library hadn’t been updated since 2008 probably means is that it’s not C++11 compliant at all, significantly behind most vendor libraries, and the effort for upgrading would be fairly significant.
I don't get the complains. Apache is abandoning it, but you can still download it, host it on Github and contribute as much as you want. That's the whole point of "free as in freedom" and, if Oracle has been unable to kill MySQL, I doubt the Apache Foundation would do it.
Shameless plug: If you'd like an actively developed, cross platform alternative C++ standard library (with Lakos allocators), come check out BSL: https://github.com/bloomberg/bsl
Sadly right now C++11 library features will lag a bit because not all compilers support them.
Sun/Oracle was moving to Apache stdcxx to replace their existing awful options of a way out of date Rogue Wave STL or an almost as out of date STLport.
Yes, they took this approach because otherwise it is a pretty monumental effort to create a C++11 std lib from scratch and they didn't have any work done on the compiler side yet.
No, I doubt it. Studio has features that don't exist in GCC/clang and there is a lot of support for older code/systems that make the newer compilers incompatible for some uses. It's just a shortcut to reuse the "easy" reusable part and focus on the compiler.
Sorry to ask but i'm confused, is it really bad that the project got declared its end of life? The source is open and anyone interested is able to continue where it left off...
I assume this means the Apache foundation will stop providing whatever services they provided. What those are, I'm unsure, but given the inactivity on the project, I assume it won't be a huge difference.
No changes. Stdcxx continues to be dormant. There was a flurry of emails
on the stdcxx-dev list suggesting continued interest from the same two
parties (ARM and Sun) but no new work.
---
The Attic is where retired Apache projects go.
(02/2012)
A vote to move stdcxx to the Attic failed. The majority of stdcxx
contributors voted in favor of continuing to maintain the project.
Several inactive committers stepped up to help with the project.
I am not familiar with the history of this project, but why was Apache trying to re-create the C++ standard library at all? Given that in GNU/Linux systems, the canonical implementation is the one provided by GCC (G++), and Microsoft provides their own implementations.
