Why are there different implementations of the C++ Standard Library?

Microsoft has it own implementation, Apache has it's own implementation. Every compiler has it's own implementation. One implementation could be different from another one. What's the reason? Why not have one universal implementation? Why reinvent the wheel?
Last edited on
Several reasons, but the main two are:

1) each implementation is designed to play to the strengths of the targeted compiler and/or hardware

2) each vendor thinks (or hopes) they can do better than another


The standard purposefully allows for different implementations, and exactly for the reasons stated above.

For example, the STL used to require that std::sort() have O(n log n) best and average case scenarios, and a minimum O(n2) worst case scenario. This is because the best general-case sort known at the time was a quicksort.

Then introsort was invented, which has an O(n log n) worst case. So now in the current C++11 standard, std::sort() is also required to have an O(n log n) worst case.

If the exact implementation of the sorting algorithm was prescribed by the standard, there would be no room for improvement.

Hope this helps.
@ Duoas

Thanks! Now I understand why.
> Apache has it's own implementation.

With the advent of C++11, the Apache C++ Standard library has been moved to attic.
STLport too lacks C++11 support.


> One implementation could be different from another one. What's the reason?

See: http://www.cplusplus.com/forum/lounge/110714/4/#msg607415
@JLBorges

So compilers base their implementation of the C++ Standard Library on the system that the compiler is to be used for?
Yes. The standard library targets the same platform which the compiler targets. And is written by the same set of programmers who write the compiler (or by a set of programmers who are intimately aware of the innards of the compiler).

This is fairly typical when a targeted third-party implementation of the library is available:

The replaceable part of the library consists of what is loosely known as “STL”, plus the string classes, the iostream classes, and their helper classes. Because these classes and headers are interdependent, replacing just a portion of them is unlikely to work. You should replace all of the headers and all of libCstd if you replace any part.

The standard headers <exception>, <new>, and <typeinfo> are tied tightly to the compiler itself and to libCrun, and cannot reliably be replaced. The library libCrun contains many “helper” functions that the compiler depends on, and cannot be replaced.

The 17 standard headers inherited from C (<stdlib.h>, <stdio.h>, <string.h>, and so forth) are tied tightly to the Solaris operating system and the basic Solaris runtime library libc, and cannot reliably be replaced. The C++ versions of those headers (<cstdlib>, <cstdio>, <cstring>, and so forth) are tied tightly to the basic C versions and cannot reliably be replaced.
http://docs.oracle.com/cd/E18659_01/html/821-1383/bkajr.html


duoas is king computer science.
If that were true I would be getting paid a lot of money to program fun things for big companies.
Topic archived. No new replies allowed.