Standard Template Library

From Free net encyclopedia

(Redirected from Standard template library)

The Standard Template Library (STL) is a software library. It is part of the [[C++ standard library|C++ Standard Library]] describing containers, iterators, and algorithms.

1 Overview
2 History
3 Contents
4 Criticisms
5 References
6 See also
7 External links

[edit]

Overview

The STL has been a major boon for [[C++]] programmers: it gives programmers a ready-made set of common classes, such as containers and associative arrays, that can be used with any built-in type and with any user-defined type that supports some elementary operations such as copying and assignment.

The STL achieves its results through the use of templates. This approach is very powerful, delivering compile-time polymorphism that is often more efficient than traditional run-time polymorphism. Modern C++ compilers are tuned to minimize any abstraction penalty arising from heavy use of the STL.

The C++ Standard Library is defined by ISO/IEC 14882.

The Standard Template Library was created as the first library of generic algorithms and data structures, with four ideas in mind: generic programming, abstractness without loss of efficiency, the Von Neumann computation model, and value semantics.

[edit]

History

The architecture of STL is largely the creation of one person, Alexander Stepanov. In 1979 he began working out his initial ideas of generic programming and exploring their potential for revolutionizing software development. Although Dave Musser had developed and advocated some aspects of generic programming as early as 1971, it was limited to a rather specialized area of software development (computer algebra).

Stepanov recognized the full potential for generic programming and persuaded his then-colleagues at General Electric Research and Development (including, primarily, Dave Musser and Deepak Kapur) that generic programming should be pursued as a comprehensive basis for software development. At the time there was no real support in any programming language for generic programming.

The first major language to provide such support was Ada, with its generic units feature. By 1987 Stepanov and Musser had developed and published an Ada library for list processing that embodied the results of much of their research on generic programming. However, Ada had not achieved much acceptance outside the defense industry and C++ seemed more likely to become widely used and provide good support for generic programming even though the language was relatively immature (it did not even have templates, added only later). Another reason for turning to C++, which Stepanov recognized early on, was the C/C++ model of computation which allows very flexible access to storage via pointers is crucial to achieving generality without losing efficiency.

Much research and experimentation were needed, not just to develop individual components, but to develop an overall architecture for a component library based on generic programming. First at AT&T Bell Laboratories and later at Hewlett-Packard Research Labs, Stepanov experimented with many architectural and algorithm formulations, first in C and later in C++. Musser collaborated in this research and in 1992 Meng Lee joined Stepanov's project at HP and became a major contributor.

This work undoubtedly would have continued for some time as just a research project or at best would have resulted in an HP proprietary library if Andrew Koenig of Bell Labs had not become aware of the work and asked Stepanov to present the main ideas at a November 1993 meeting of the ANSI/ISO committee for C++ standardization. The committee's response was overwhelmingly favorable and led to a request from Koenig for a formal proposal in time for the March 1994 meeting. Despite the tremendous time pressure, Alex and Meng were able to produce a draft proposal that received preliminary approval at that meeting.

The committee had several requests for changes and extensions (some of them major), and a small group of committee members met with Stepanov and Lee to help work out the details. The requirements for the most significant extension (associative containers) had to be shown to be consistent by fully implementing them, a task Stepanov delegated to Musser. It would have been quite easy for the whole enterprise to spin out of control at this point, but again Stepanov and Lee met the challenge and produced a proposal that received final approval at the July 1994 ANSI/ISO committee meeting. (Additional details of this history can be found in an interview Alexander Stepanov gave in the March 1995 issue of Dr. Dobb's Journal [1].)

Subsequently, the Stepanov and Lee document 17 was incorporated into the ANSI/ISO C++ draft standard (1, parts of clauses 17 through 27). It also influenced other parts of the C++ Standard Library, such as the string facilities, and some of the previously adopted standards in those areas were revised accordingly.

In spite of STL's success with the committee, there remained the question of how STL would make its way into actual availability and use. With the STL requirements part of the publicly available draft standard, compiler vendors and independent software library vendors could of course develop their own implementations and market them as separate products or as selling points for their other wares. One of the first edition's authors, Atul Saini, was among the first to recognize the commercial potential and began exploring it as a line of business for his company, Modena Software Incorporated, even before STL had been fully accepted by the committee.

The prospects for early widespread dissemination of STL were considerably improved with Hewlett-Packard's decision to make its implementation freely available on the Internet in August 1994. This implementation, developed by Stepanov, Lee, and Musser during the standardization process, became the basis of many implementations offered by compiler and library vendors today.

[edit]

Containers

The STL contains sequence containers and associative containers. The standard sequence containers include vector, string, deque and list. The standard associative containers are set, multiset, map and multimap.

vector - a C-like array (i.e., capable of random access) with the ability to automatically resize itself when inserting or erasing an object. Inserting and removing an element to/from back of the vector at the end takes constant time. Inserting and erasing at the beginning or in the middle is linear in time.

list - like an array, but without the guarantee that its elements are stored in contiguous memory. Opposite performance from a vector. Slow lookup and access (linear time), but once a position has been found, quick insertion and deletion (constant time).

deque (double ended queue) - a vector with insertion/erase at the beginning in amortized constant time, however lacking some guarantees on iterator validity after altering the deque.

set - inserting/erasing elements in a set does not invalidate iterators pointing in the set. Provides set operations union, intersection, difference, symmetric difference and test of inclusion.

multiset - same as a set, but allows duplicate elements.

map - allows mapping from one data item (a key) to another (a value). Typical implementations use red-black tree to implement map.

multimap - same as a map, but allows duplicate keys.

Libraries implementing STL often include hashed variants: hash_set, hash_multiset, hash_map and hash_multimap, but these extensions are not part of the standard and are defined in various namespaces among implementations as a result.

[edit]

Iterators

The STL implements five different types of iterators. These are input iterators (which can only be used to read a sequence of values), output iterators (which can only be used to write a sequence of values), forward iterators (which can be read, written to, and move forward), bidirectional iterators (which are like forward iterators but can also move backwards) and random access iterators (which can move freely any number of steps in one operation).

It is possible to have bidirectional iterators act like random access iterators, as moving forward ten steps could be done by simply moving forward a step at a time a total of ten times. However, having distinct random access iterators offers efficiency advantages. For example, a vector would have a random access iterator, but a list only a bidirectional iterator.

Iterators are the major feature which allow the generality of the STL. For example, an algorithm to reverse a sequence can be implemented using bidirectional iterators, and then the same implementation can be used on lists, vectors and deques. User-created containers only have to provide an iterator which implements the one of the 5 standard iterator interfaces, and all the algorithms provided in the STL can be used on their container.

This generality also comes at a price at times. For example, performing a search on an associative container such as a map or set can be much slower using iterators than by calling member functions offered by the container itself. This is because an associative container can take advantage of knowing how it is internally structured whereas iterators have no way of knowing such information.

[edit]

Algorithms

A large number of algorithms to perform operations such as searching and sorting are provided in the STL, each implemented to require a certain level of iterator (and therefore will work on any container which provides an interface by iterators).

[edit]

Functors

The STL includes classes that overload the function operator (operator()). Classes that do this are called functors or function objects. They are useful for keeping and retrieving state information in functions passed into other functions.

A particularily common type of functor is the predicate. For example, algorithms like find_if take a unary predicate that operates on the elements of a sequence. Algorithms like sort, partial_sort, nth_element and all sorted containers use a binary predicate which must provide a strict weak ordering, that is, it must behave like a membership test on a transitive, irreflexive and antisymmetric binary relation. If none is supplied, these algorithms and containers use less by default, which in turn calls the less-than-operator <.

[edit]

Criticisms

No system is perfect, and there are some drawbacks to STL:

Error messages tend to be very long and difficult to decipher. This problem has been considered so severe that a number of tools have been written which simplify and indent STL-related error messages to make them more comprehensible.
Because the code is generated at compile time, some compilers are poor at tracing the error back to the coder-written source, which can cause slow debugging.
Initialization of STL containers with constants within the source code is not straightforward.
STL containers must be very carefully used as a base class because their destructors are deliberately non-virtual.
Template instantiation tends to increase compiler time and memory usage.
Careless use of STL templates can lead to code bloat.

[edit]