Closing and References

Templates and exceptions are both topics that deserve much more room than I've allocated in this article. For more details on templates, you may wish to consult The C++ Programming Language, 3rd Edition by Bjarne Stroustrup or C++ Templates - The Complete Guide by David Vandevoorde and Nicolai Josuttis. Also, the C++ FAQ Lite contains many useful insights into specific issues in template programming.

For more details on exceptions, you may want to consult again The C++ Programming Language, 3rd Edition by Bjarne Stroustrup, and especially the hard cover version of the book which has an additional section on exception handling in the end. Other good books for learning about exception handling include Exceptional C++ and More Exceptional C+ by Herb Sutter, and C++ Gotchas by Steven Dewhurst. Again, the C++ FAQ Lite covers many common issues about exception handling.

There are a few details missing from my coverage about namespaces, which again can be found in The C++ Programming Language, 3rd Edition by Bjarne Stroustrup.

General references for the standard library as a whole include yet again, The C++ Programming Language, 3rd Edition by Bjarne Stroustrup and also The C++ Standard Library by Nicolai Josuttis and of course the actual text of the C++ Standard: ISO/IEC 14882:2003, which can be found either as hardcover as The C++ Standard: Incorporating Technical Corrigendum No. 1 from Wiley or from your national standards body. For example, for the United States, it can be found both printed and for electronic download (for a fee) from ANSI. [14] You can visit the C++ Standard Committee's website here. In particular you can download draft copies of the C++ Standard there, which, while they are not up to date, are free. This includes the TR1 paper. Generally speaking the differences between the draft and final versions of the papers are minor.

Also, I will also be referring to the Boost project quite a bit as well.

If you are interested in the pre-standards history of C++ (including much of what makes up the modern standard library) consider reading The Design and Evolution of C++ by Bjarne Stroustrup, or The Annotated C++ Reference Manual by Margaret Ellis and Bjarne Stroustrup.

A different approach to introducing the standard library, and the C++ language as a whole, is taken by the book Accelerated C++ by Andrew Koenig and Barbara Moo. If the approach taken in this article series doesn't work for you, you may want to try reading that book.

In the next article I'll cover one of the more useful of the standard library classes: std::vector.

1) If you aren't that comfortable with header files you may wish to read this article.

2) To be pedantic, Technical Report 1 is non-normative, so compiler vendors are not under any obligation to provide the library features detailed in Technical Report 1.

3) This is called Koenig lookup.

4) However, you can use using directives and declarations in a class member function's implementation.

5) Unless, for some bizarre reason, your compiler's <iostream> header directly or indirectly includes <vector>.

6) Many people use the convention of using typename when the template argument can be any type including primitives, and using class when the template argument must be a class. An exception is that template-template parameters require the class keyword. However, template-template parameters are outside the scope of this article as the C++ Standard Library does not use them.

7) This is something that will probably change in the next version of the C++ Standard.

8) Not compilers will. However, the ones that don't tend to be older compilers that look up all names at the point on instantiation.

9) It also generates the same headaches for the linker that inline functions do.

10) Also, the export keyword doesn't work like you might expect it would as it doesn't allow for true seperate compilation of templates. For more details see these articles: "Export" Restrictions, Part 1 and "Export" Restrictions, Part 2.

11) And you can't get away from them. The language itself will throw exceptions in many cases. For example, if memory allocation fails in a new expression, an exception will be thrown. If a dynamic_cast to a reference type fails an exception will be thrown.

12) Catching by value can lead to problems such as slicing, where you lose information about the exception being caught. Another issue is that sometimes catching by value may invoke a copy constructor that itself may throw an exception. Throwing an exception while doing exception handling is a bad thing.

13) Actually, you can also specify that a function will only throw certain exceptions.

// will only throw SomeException and SomeOtherException
void function1(void) throw(SomeException, SomeOtherException) {
  // stuff
}

Exception specifications were introduced with the hope that it would allow certain optimizations. However, the way that exception specifications were defined in the standard generally makes them perform worse than functions without an exception specification. Also, even now, many compilers do not actually implement exceptions specifications other than throw(). At this point, I would recommend not to use them at all, including not using throw(). (Again, unless it's required by an interface.)

14) However, the hard cover version from Wiley is much less expensive than the version from ANSI.