Karl MacMillan ("karlmac@mail.dkc.mse.jhu.edu") writes:

The standard STL doesn't have a hash_map, but it is a common extension. There is a map object that will work in most instances, however.

I don't doubt Karl's good intentions, but one should be careful not to propagate the misconception that the Standard Template Library (STL) is part of C++. While there's considerable overlap, each contains something that the other lacks, and there are occasional differences between components that might appear identical at first glance.

As of this writing, the definitive C++ reference is ISO/IEC 14882-1998. In the future, what we know as C++ will probably be known as C++98, just as the arrival of ISO/IEC 9899:1999 has forced programmers to distinguish between "C89" and "C99".

For the record, the Standard Template Library (STL) does contain a "hash_map" template. It also contains things like "rope", "slist", "hash_multimap", "hash_multiset", "binary_compose", etc. that are not in ISO/IEC 14882-1998.

There are also some subtle differences between certain components in the STL and their counterparts in ISO/IEC 14882-1998: for example, in the STL, the codomain of a "std::map" is typedefed as "data_type"; in C++98, it's "mapped_type".

ISO/IEC 14882-1998 specifies a "Containers library" (see Section 23 of ISO/IEC 14882-1998) and an Algorithms library (see Section 25 of ISO/IEC 14882-1998), but nowhere in ISO/IEC 14882-1998 will you see the phrases "Standard Template Library" or "STL".

The next C++ standard will almost certainly increase compatibility with C99 and the STL. It's nearly certain that a "hash_map" will be added. It's also very likely that some of the components in the Boost project will be added. In the meantime, it's not hard to write a "hash_map" yourself if you're in an environent that doesn't provide it.

(It may be stating the obvious, but many C++ programmers fail to realize that if you don't like the performance of a particular STL/SAL algorithm or STL/SCL container, you're free to write your own, and if you do it properly, it will still interact with other STL/SAL/SCL components as if it were part of the STL/SAL/SCL.)

References:

Standards:

The definitive STL reference is here: "http://www.sgi.com/tech/stl/" (It's definitive because Alexander Stepanov still works at SGI.)

C99: ISO/IEC 9899:1999 (see http://www.iso.org) C++98: ISO/IEC 14882-1998 (see http://www.iso.org)

(Since ISO/IEC 9899:1999 and ISO/IEC 14882-1998 can be purchased in PDF-file form for approx. $15 each, and since a suitable copy of Adobe's Acrobat Reader is available free of charge for most major platforms, there are few conceivable excuses for not having these documents available for immediate perusal while you're programming.)

Handy references for generative programming, generic programming, template metaprogramming, preprocessor metaprogramming, etc.:

http://www.boost.org http://www.oonumerics.org/blitz/

http://home.t-online.de/home/Ulrich.Eisenecker/meta.htm http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html http://community.borland.com/article/print/0,1772,10526,00.html http://www.hpc.uwindsor.ca/seminars/2002-03-22/cpptm/

Modern C++ Design: Generic Programming and Design Patterns Applied by Andrei Alexandrescu Paperback: 352 pages Dimensions (in inches): 0.69 x 9.17 x 7.35 Publisher: Addison Wesley Professional ISBN: 0201704315 1st edition (February 13, 2001)

The C++ Standard Library: A Tutorial and Reference by Nicolai M. Josuttis Hardcover: 832 pages Dimensions (in inches): 1.67 x 9.46 x 7.88 Publisher: Addison-Wesley Pub Co ISBN: 0201379260 1st edition (August 12, 1999)

Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library by Scott Meyers Paperback: 288 pages Dimensions (in inches): 0.69 x 9.21 x 7.43 Publisher: Addison-Wesley Pub Co ISBN: 0201749629 1st edition (June 6, 2001)

Standard C++ IOStreams and Locales: Advanced Programmer's Guide and Reference by Angelika Langer, Klaus Kreft Hardcover: 672 pages Dimensions (in inches): 1.38 x 9.56 x 7.72 Publisher: Addison-Wesley Pub Co ISBN: 0201183951 1st edition (January 31, 2000) (not really related to generic programming, but a good reference nonetheless)

John J. Barton, Lee R. Nackman Scientific and Engineering C++: An Introduction With Advanced Techniques and Examples Hardcover: 671 pages Dimensions (in inches): 1.18 x 9.52 x 7.67 Publisher: Addison-Wesley Pub Co ISBN: 0201533936 1st edition (July 1994)

I use the STL and like it because it is powerful and fast. Other people avoid it like the plague, though!

The onus is on the latter to explain why they're avoiding it. The only defensible reasons I can think of are that (1) you're forced to support a legacy environment that doesn't support ISO/IEC 14882-1998 or (2) your environment provides a poor implementation of the STL/SAL/SCL. For an example of #2, the Sun WorkShop C++ 5.x compilers introduce pessimizations when you're compiling in multithreaded mode: string and IOstream operations are serialized with mutex operations, which are very heavy. You could disable some of these mutex operations in run-time with the Sun WorkShop C++ 4.2 compiler, but with the Sun WorkShop C++ 5.x compiler, you're stuck with them. String and stream access can be real bottlenecks. I would argue that this is an implementation flaw on Sun's behalf. (There's a strong argument to be made that the C++ committee was too naïve in this regard, but that's beyond the scope of this forum.)

Those concerns aside, avoiding the STL/SAL/SCL like the plague is, IMHO, is even more childish than avoiding multiple inheritance.