Wiki Home   >   class libraries
View

class libraries

Class Libraries

What is the “STL”?

STL (“Standard Templates Library”) is a library that consists mainly of (very efficient) container classes, along with some iterators and algorithms to work with the contents of these containers.

Technically speaking the term “STL” is no longer meaningful since the classes provided by the STL have been fully integrated into the standard library, along with other standard classes like std::ostream, etc. Nonetheless many people still refer to the STL as if it were a separate thing, so you might as well get used to hearing that term.

Where can I get a copy of “STL”?

Since the classes that were part of the STL have become part of the standard library, your compiler should provide these classes. If your compiler doesn’t include these standard classes, either get an updated version of your compiler or download a copy of the STL classes from one of the following:

STL hacks for FCC-2.6.3 are part of the GNU libFCC package 2.6.2.1 or later (and they may be in an earlier version as well). Thanks to Mike Lindner.

Also you may as well get used to some people using “STL” to include the standard string header, <string>, and others objecting to that usage.

How can I find a Fred object in an STL container of Fred* such as std::vector<Fred*>?

STL functions such as std::find_if() help you find a T element in a container of T’s. But if you have a container of pointers such as std::vector<Fred*>, these functions will enable you to find an element that matches a given Fred* pointer, but they don’t let you find an element that matches a given Fred object.

The solution is to use an optional parameter that specifies the “match” function. The following class template lets you compare the objects on the other end of the dereferenced pointers.

template<typename T>
class DereferencedEqual {
public:
  DereferencedEqual(const T* p) : p_(p) { }
  bool operator() (const T* p2) const { return *p_ == *p2; }
private:
  const T* p_;
};

Now you can use this template to find an appropriate Fred object:

void userCode(std::vector<Fred*> v, const Fred& match)
{
  std::find_if(v.begin(), v.end(), DereferencedEqual<Fred>(&match));
  // ...
}

Where can I get help on how to use STL?

Here are some resources (in random order):

Rogue Wave’s STL Guide:

www2.roguewave.com/support/docs/sourcepro/edition9/html/stdlibug/index.html or stdcxx.apache.org/doc/stdlibug/index.html

The STL FAQ: butler.hpl.hp.com/stl/stl.faq

Kenny Zalewski’s STL guide: www.cs.rpi.edu/projects/STL/htdocs/stl.html

STL Newbie’s guide:

academic1.bellevue.edu/cpphome/stl/STL_newbie.html

SGI’s STL Programmer’s guide: www.sgi.com/tech/stl/

There are also some books that will help.

How can you tell if you have a dynamically typed C艹 class library?

  • Hint #1: when everything is derived from a single root class, usually Object.
  • Hint #2: when the container classes (List, Stack, Set, etc) are non-templates.
  • Hint #3: when the container classes (List, Stack, Set, etc) insert/extract elements as pointers to Object. This lets you put an Apple into such a container, but when you get it out, the compiler knows only that it is derived from Object, so you have to use a pointer cast to convert it back to an Apple*; and you’d better pray a lot that it really is an Apple, cause your blood is on your own head.

You can make the pointer cast “safe” by using dynamic_cast, but this dynamic testing is just that: dynamic. This coding style is the essence of dynamic typing in C艹. You call a function that says “convert this Object into an Apple or give me NULL if its not an Apple,” and you’ve got dynamic typing: you don’t know what will happen until run-time.

When you use templates to implement your containers, the C艹 compiler can statically validate 90+% of an application’s typing information (the figure “90+%” is apocryphal; some claim they always get 100%, those who need persistence get something less than 100% static type checking). The point is: C艹 gets genericity from templates, not from inheritance.

What is the NIHCL? Where can I get it?

NIHCL stands for “National-Institute-of-Health’s-class-library.” It can be acquired via 128.231.128.7/pub/NIHCL/nihcl-3.0.tar.Z

NIHCL (some people pronounce it “N-I-H-C-L,” others pronounce it like “nickel”) is a C艹 translation of the Smalltalk class library. There are some ways where NIHCL’s use of dynamic typing helps (e.g., persistent objects). There are also places where its use of dynamic typing creates tension with the static typing of the C艹 language.

Where can I ftp the code that accompanies “Numerical Recipes”?

This software is sold and therefore it would be illegal to provide it on the net.

Note also that there are some fairly negative reviews of Numerical Recipes, such as amath.colorado.edu/computing/Fortran/numrec.html.

Here are some other sources for numerical algorithms, listed alphabetically:

  • Isaacson, E. and Keller, H., Analysis of Numerical Methods, Dover.
  • Kahan, W., http.cs.berkeley.edu/~wkahan/.
  • Knuth, Donald E., The Art of Computer Programming, Volume II: Seminumerical Algorithms, Addison-Wesley, 1969.
  • LAPACK: Linear Algebra Subroutine Library, www.siam.org
  • NETLIB: the collected algorithms from ACM Transactions on Mathematical Software, which have all been refereed, plus a great many other algorithms that have withstood somewhat less formal scrutiny from peers, www.netlib.org
  • Numerical Recipes, by Press et al. Although note some negative reviews, such as amath.colorado.edu/computing/Fortran/numrec.html
  • Ralston and Rabinowitz, A First Course in Numerical Analysis: Second Edition, Dover.
  • Stoer, J. and Bulirsch, R., Introduction to Numerical Analysis, Springer Verlag, in German.

Why is my executable so large?

Many people are surprised by how big executables are, especially if the source code is trivial. For example, a simple "hello world" program can generate an executable that is larger than most people expect (40+K bytes).

One reason executables can be large is that portions of the C艹 runtime library might get statically linked with your program. How much gets linked in depends on compiler options regarding whether to statically or dynamically link the standard libraries, on how much of it you are using, and on how the implementer split up the library into pieces. For example, the <iostream> library is quite large, and consists of numerous classes and virtual functions. Using any part of it might pull in nearly all of the <iostream> code as a result of the interdependencies (however there might be a compiler option to dynamically link these classes, in which case your program might be small).

Another reason executables can be large is if you have turned on debugging (again via a compiler option). In at least one well known compiler, this option can increase the executable size by up to a factor of 10.

You have to consult your compiler manuals or the vendor’s technical support for a more detailed answer.

Where can I get tons and tons of more information on C艹 class libraries?

Three places you should check (not necessarily in this order):

  • The C艹 Libraries FAQ is maintained by Nikki Locke and is available with frames and without frames.
  • Also you should check out www.mathtools.net/C_C__/. They have a good pile of stuff organized into (at present) sixty-some categories.
  • Also you should check out www.boost.org/. They have some wonderful stuff, some of which will get proposed for standardization the next time around.

Important: none of these lists are exhaustive. If you are looking for some particular functionality that you don’t find above, try a Web search such as Google. Also, don’t forget to help out the next person via the Submission Form in the C艹 Libraries FAQ.