STL Gotchas - Avoiding Common Errors in Using the STL
The standard C++ library and the STL – and in particular
its containers and algorithms - are an indispensable part of every C++
programmer's knowledge of the language. Like every tools it increases productivity
and reliability of the resulting software, yet it needs to be mastered
before it can be used effectively.
Textbooks and courses teach provide tutorials to the STL and enable
programmers to use the STL containers and algorithms. In practice, it turns
out that there are several hurdles to surmount, before the STL fits into
every-day programming smoothly and safely.
Examples of known problem areas:
These and other problem zones of the STL are explored in this tutorial.
Knowing them ahead of time saves a lot of development and testing time.
While some of the problems lead to compile-time errors, they are still
hard to identify, because contemporary compilers issue almost unreadable
error message when templates are used intensely. Other errors will result
in run-time errors and are even harder to track down. The tutorial aims
to increase the awareness of potential problems and helps avoiding the
errors in the first place.
INVALIDATION OF ITERATORS.
Iterators are pointer-like
objects that refer to elements maintained in a STL container. Depending
on the type of the container, any operations performed on the container
might invalidate any iterators pointing to elements in the container. Ever
too often, programmers overlook this side-effect and as a result, have
to cope with errors that are hard to track down - pretty much like traditional
The associative containers
in the STL must not allow modification of the key values that determine
the ordering of the underlying binary-tree-structure. Depending on the
implementation this might be expressed in terms of all iterators being
constant iterators, which imposes severe restrictions on the usability
of the container, or the iterators are non-constant iterators, which allows
inadvertant corruption of the tree-structure. How do we cope?
SIDE-EFFECT-FREE FUNCTION OBJECTS.
Use of function
object types is a programming idiom central to the STL. The STL specification
imposes restrictions on the functionality of function objects that can
be used in conjunction with the STL: they must not have side effects and
they must not modify the container element through a dereferenced iterator.
What does it mean in pratice?
EQUALITY VS. EQUIVALENCE.
While most algorithms
use an equality relation, typically
when they check for equal values, the associative containers use a deduced
equivalence, typically deduced from
When does equality differ from equivalence, and what difference does it
Stream iterators are a powerful
and convenient abstraction that permit treating input and output devices
as sequences of elements of the same type. Yet they have interesting semantics
in the sense that several iterators on the same stream are not independent
of each other, the result of which can be surprising. Learn more about
USABILITY OF AUTO POINTERS.
The auto pointer
abstraction in the STL is designed to solve problems regarding management
of heap objects in presence of exceptions: it automatically deletes the
heap object it owns in order to prevent memory leaks. However, use of the
auto pointer in conjunction with the STL leads to surprising results.
and containers take strategy objects: a
algorithm can be provided with a comparator which it uses for comparison
of container elements. If such strategy objects are implemented using the
strategy pattern, run-time polymorphism is likely to be involved, which
again leads to subtle problems with the STL.
Attendants should have gained a certain degree of familiarity
with the STL.
Munich, Germany, January 2000
DevWeek Europe 2000
UK, February 2000
Zürich, CH, March 2000
If you are interested to hear more about this
and related topics you might want to check out the following seminars or
skim through some further reading: