[PD-dev] STL & C++ & platforms - a question

[jdavison at speakeasy.org]

Karl MacMillan ("karlmac at 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.

-- 
John Davison, jdavison at-sign speakeasy period org