Thinking in C++ 2nd ed Volume 2
Note: This document requires the installation of the fonts
Georgia, Verdana and Andale Mono (code font) for proper viewing.
These can be found at:
http://sourceforge.net/project/showfiles.php?group_id=34153&release_id=105355
Revision 15 (March 1 ,2003)
Fixed an omission in C10:CuriousSingleton.cpp. Chapters 9 and 10
have been tech-edited.
Revision 14 (January ,2003)
Fixed a number of fuzzy explanations in response to reader
feedback (thanks!). Chapter 9 has been copy-edited.
Revision 13 (December 31, 2002)
Updated the exercises for Chapter 7. Finished rewriting Chapter
9. Added a template variation of Singleton to chapter 10. Updated
the build directives. Fixed lotsa stuff. Chapters 5 and 11 still
await rewrite.
Revision 12 (December 23, 2002)
Added material on Design Patterns as Chapter 10 (Concurrency
will move to Chapter 11). Added exercises for Chapter 6. Here is
the status of all chapters:
100% complete: 1-4, 6, 8
Copy-edited, waiting for tech edit: 7, 10
Incomplete: 5, 9, 11
Revision 11 (December 13, 2002)
Chapter 7 has been updated. Chapter 6 has been copy-edited and a
few bugs were fixed. Chapter 4 has been tech-edited. The exercises
are still out of date except for chapters 1-3.
Revision 10 (October 15, 2002)
Chapters 1 through 3 are now 100% complete (copy-edited and
tech-edited). Chapter 4 has been copy-edited. Updated Chapter 6 to
fit in its new position and adding introductory material. (Chapters
5 and 7-10 are still unfinished at this point).
Revision 9 (August 29, 2002)
Finished Chapter 4 (IOStreams). Reordered the material and added
material on wide stream and locales. Removed references to
strstreams. Edited the Iostreams examples section. Added new
exercises.
Revision 8 (August 6, 2002) --
Made ExtractCode.cpp in Chapter 3 work for GNU C++.
Copy-edited Chapters 1 through 3.
Revision 7 (July 31, 2002) --
Fixed omissions in comments for code extraction throughout
text.
Edited Chapter 3:
Added a wide-character version of ichar_traits
Replaced SiteMapConvert.cpp with ExtractCode.cpp
Added exercises
Revision 6 (July 27, 2002) --
Finished Chapter 3 (Strings)
Mentioned caveat about reference counting with
multithreading.
Removed first (out-of-date) HTML example
Fixed the ichar_traits example
Fixed stupid MemCheck.cpp error in Chapter 2
Revision 5 (July 20, 2002) --
Chapters 1 and 2 are finished.
Reordered the material in Chapter 1:
Placed exception specifications last, and warned of their
dangers with template classes
Added a section on Exception Safety.
Added material on auto_ptr
Added material illustrating bad_exception
Explained the internal implementation of exceptions and the
Zero-cost Model
Merged Chapter 3 (Debugging) into Chapter 2:
Added material on invariants, assertions and
Design-by-contract
Placed the TestSuite in its own namespace
Finished the MemCheck system for tracking memory errors
Removed Chapter 11 (Design Patterns)
Will be replaced by Chapter 10 (Concurrent Programming)
Revision 4, August 19, 2001 --
Restructured the book; this is the first version with Chuck
Allison coauthoring. Incorporated Chuck's testing framework, which
will be used throughout the book and automatically included as part
of the book's build process in the makefiles.
In the code subdirectory of the unpacked distribution, you can
now use make to compile for Borland, Microsoft, Gnu g++2.95
(distributed with Cygwin) and Gnu g++3.0 (tested under Linux).
Under Windows98/NT/2000, you will get best results running under
the free Cygwin environment (www.Cygwin.com), even if you're
compiling for Borland or Microsoft. In particular, some linker
command lines for Microsoft are too long for Win98 COMMAND.COM, but
work just fine under Cygwin.
Made many code changes to allow programs to be run inside the
test framework, in particular removing the need for user input when
executing programs.
Added //{L} ../TestSuite/Test in all the programs that can be
run without user input, to cause the makefile builder to generate
calls to the programs as part of the build process.
This book is a tremendous achievement. You owe it to yourself to
have a copy on your shelf. The chapter on iostreams is the most
comprehensive and understandable treatment of that subject Ive seen
to date.
Al Stevens Contributing Editor, Doctor Dobbs Journal
Eckels book is the only one to so clearly explain how to rethink
program construction for object orientation. That the book is also
an excellent tutorial on the ins and outs of C++ is an added
bonus.
Andrew BinstockEditor, Unix Review
Bruce continues to amaze me with his insight into C++, and
Thinking in C++ is his best collection of ideas yet. If you want
clear answers to difficult questions about C++, buy this
outstanding book.
Gary EntsmingerAuthor, The Tao of Objects
Thinking in C++ patiently and methodically explores the issues
of when and how to use inlines, references, operator overloading,
inheritance and dynamic objects, as well as advanced topics such as
the proper use of templates, exceptions and multiple inheritance.
The entire effort is woven in a fabric that includes Eckels own
philosophy of object and program design. A must for every C++
developers bookshelf, Thinking in C++ is the one C++ book you must
have if youre doing serious development with C++.
Richard Hale ShawContributing Editor, PC Magazine
Thinking
In
C++
2nd EditionVolume 2: Practical Programming
Bruce Eckel, President, MindView Inc.Chuck Allison, Utah Valley
State College
2002 MindView, Inc.
The information in this book is distributed on an as is basis,
without warranty. While every precaution has been taken in the
preparation of this book, neither the author nor the publisher
shall have any liability to any person or entitle with respect to
any liability, loss or damage caused or alleged to be caused
directly or indirectly by instructions contained in this book or by
the computer software or hardware products described herein.
All rights reserved. No part of this book may be reproduced in
any form or by any electronic or mechanical means including
information storage and retrieval systems without permission in
writing from the publisher or authors, except by a reviewer who may
quote brief passages in a review. Any of the names used in the
examples and text of this book are fictional; any relationship to
persons living or dead or to fictional characters in other works is
purely coincidental.
dedication
To all those who have tirelessly worked toward the development
of the C++ language
Whats inside...
17Preface
Goals17
Chapters18
Exercises20
Exercise solutions20
Source code20
Language standards22
Language support22
Seminars, CD-ROMs & consulting22
Errors23
About the cover23
Acknowledgements23
Part 1: Building Stable Systems27
1: Exception handling29
Error handling in C30
Throwing an exception33
Catching an exception34
The try block34
Exception handlers35
Exception matching38
Catching any exception40
Re-throwing an exception41
Uncaught exceptions42
Cleaning up44
Resource management46
Making everything an object48
auto_ptr51
Function-level try blocks52
Standard exceptions54
Exception specifications58
Better exception specifications?63
Exception specifications and inheritance64
When not to use exception specifications66
Exception safety66
Programming with exceptions71
When to avoid exceptions71
Typical uses of exceptions74
Overhead77
Summary80
Exercises81
2: Defensive programming83
Assertions86
The simplest automated unit test framework that could possibly
work91
Automated testing93
The TestSuite Framework97
Test suites101
The test framework code103
Debugging techniques111
Trace macros111
Trace file112
Finding memory leaks113
Summary121
Exercises121
Part 2: The Standard C++ Library125
3: Strings in depth128
Whats in a string?129
Creating and initializing C++ strings131
Operating on strings135
Appending, inserting, and concatenating strings136
Replacing string characters138
Concatenation using nonmember overloaded operators143
Searching in strings144
Finding in reverse149
Finding first/last of a set of characters151
Removing characters from strings153
Comparing strings155
Strings and character traits160
A string application167
Summary173
Exercises174
4: Iostreams175
Why iostreams?175
Iostreams to the rescue181
Inserters and extractors181
Common usage186
Line-oriented input189
Handling stream errors191
File iostreams194
A File-Processing Example196
Open modes198
Iostream buffering199
Seeking in iostreams203
String iostreams206
Input string streams207
Output string streams209
Output stream formatting213
Format flags214
Format fields216
Width, fill, and precision218
An exhaustive example219
Manipulators223
Manipulators with arguments224
Creating manipulators228
Effectors230
Iostream examples232
Maintaining class library source code233
Detecting compiler errors238
A simple datalogger240
Internationalization246
Wide Streams246
Locales249
Summary252
Exercises253
5: Templates in depth255
Nontype template arguments255
Default template arguments256
The typename keyword256
Typedefing a typename258
Using typename instead of class258
Function templates259
A string conversion system259
A memory allocation system261
Type induction in function templates265
Taking the address of a generated function template266
Local classes in templates267
Applying a function to an STL sequence267
Template-templates270
Member function templates271
Why virtual member template functions are disallowed274
Nested template classes274
Template specializations274
Full specialization274
Partial Specialization274
A practical example274
Design & efficiency278
Preventing template bloat278
Explicit instantiation280
Explicit specification of template functions281
Controlling template instantiation281
The inclusion vs. separation models283
The export keyword283
Template programming idioms283
The curiously-recurring template283
Implementing Locales283
Traits283
Template Metaprogramming283
Expression Templates283
Compile-time Assertions283
Summary283
Exercises284
6: Generic algorithms285
A first look285
Predicates289
Stream iterators292
Algorithm complexity294
Function objects296
Classification of function objects298
Automatic creation of function objects299
Adaptable function objects303
More function object examples305
Function pointer adapters314
Writing your own function object adapters322
A catalog of STL algorithms327
Support tools for example creation330
Filling and generating333
Counting335
Manipulating sequences337
Searching and replacing343
Comparing ranges351
Removing elements356
Sorting and operations on sorted ranges360
Heap operations371
Applying an operation to each element in a range373
Numeric algorithms383
General utilities387
Creating your own STL-style algorithms389
Summary390
Exercises391
7: Generic containers399
Containers and iterators399
STL reference documentation402
A first look402
Containers of strings409
Inheriting from STL containers411
A plethora of iterators414
Iterators in reversible containers417
Iterator categories418
Predefined iterators420
The basic sequences: vector, list, deque426
Basic sequence operations427
vector430
deque439
Converting between sequences442
Checked random-access444
list446
Swapping basic sequences453
set454
A completely reusable tokenizer458
stack464
queue468
Priority queues474
Holding bits484
bitset485
vector490
Associative containers492
Generators and fillers for associative containers497
The magic of maps501
Multimaps and duplicate keys507
Multisets511
Combining STL containers515
Cleaning up containers of pointers519
Creating your own containers521
STL extensions524
Non-STL containers526
Summary530
Exercises531
Part 3: Special Topics535
8: Runtime type identification537
Runtime casts537
The typeid operator543
Casting to intermediate levels546
void pointers547
Using RTTI with templates548
Multiple inheritance549
Sensible uses for RTTI550
A trash recycler551
Mechanism and overhead of RTTI557
Summary558
Exercises558
9: Multiple inheritance560
Perspective560
Interface inheritance563
Implementation inheritance567
Duplicate subobjects574
Virtual base classes579
Name lookup issues590
Avoiding MI594
Extending an interface594
Summary599
Exercises600
10: Design patterns601
The pattern concept601
The singleton603
Variations on singleton604
Classifying patterns610
Features, idioms, patterns611
Building complex objects612
Factories: encapsulating object creation620
Polymorphic factories623
Abstract factories627
Virtual constructors630
Observer637
The interface idiom The inner class idiom641
The observer example645
Multiple dispatching649
Multiple dispatching with Visitor653
Exercises656
11: Concurrent programming659
A: Recommended reading661
C661
General C++661
Bruces books662
Depth & dark corners663
The STL663
Design Patterns663
B: Etc665
Index674
Preface
In Volume 1 of this book, you learn the fundamentals of C and
C++. In this volume, we look at more advanced features, with an eye
towards developing techniques and ideas that produce robust C++
programs.
Thus, in this volume we are assuming that you are competent with
the material developed in Volume 1. Comment
Goals
Our goals in this book are to:Comment
1. Present the material a simple step at a time, so the reader
can easily digest each concept before moving on.
2. Teach practical programming techniques that you can use on a
day-to-day basis.
3. Give you what we think is important for you to understand
about the language, rather than everything we know. We believe
there is an information importance hierarchy, and there are some
facts that 95% of programmers will never need to know, but that
would just confuse people and add to their perception of the
complexity of the language. To take an example from C, if you
memorize the operator precedence table (we never did) you can write
clever code. But if you have to think about it, it will confuse the
reader/maintainer of that code. So forget about precedence, and use
parentheses when things arent clear. This same attitude will be
taken with some information in the C++ language, which is more
important for compiler writers than for programmers.
4. Keep each section focused enough so the lecture time and the
time between exercise periods is small. Not only does this keep the
audience minds more active and involved during a hands-on seminar,
but it gives the reader a greater sense of accomplishment.
5. We have endeavored not to use any particular vendors version
of C++. We have tested the code on all the implementations we
could, and when one implementation absolutely refused to work
because it doesnt conform to the C++ Standard, weve flagged that
fact in the example (youll see the flags in the source code) to
exclude it from the build process.
6. Automate the compiling and testing of the code in the book.
We have discovered that code that isnt compiled and tested is
probably broken, so in this volume weve instrumented the examples
with test code. In addition, the code that you can download from
http://www.MindView.net has been extracted directly from the text
of the book using programs that also automatically create makefiles
to compile and run the tests. This way we know that the code in the
book is correct.
Chapters
Here is a brief description of the chapters contained in this
book:
Part 1: Building Stable Systems
1. Exception handling. Error handling has always been a problem
in programming. Even if you dutifully return error information or
set a flag, the function caller may simply ignore it. Exception
handling is a primary feature in C++ that solves this problem by
allowing you to throw an object out of your function when a
critical error happens. You throw different types of objects for
different errors, and the function caller catches these objects in
separate error handling routines. If you throw an exception, it
cannot be ignored, so you can guarantee that something will happen
in response to your error.Comment
2. Defensive Programming. (Description)
Part 2: The Standard C++ Library
3. Strings in Depth. (Description)
4. Iostreams. One of the original C++ libraries the one that
provides the essential I/O facility is called iostreams. Iostreams
is intended to replace Cs stdio.h with an I/O library that is
easier to use, more flexible, and extensible you can adapt it to
work with your new classes. This chapter teaches you the ins and
outs of how to make the best use of the existing iostream library
for standard I/O, file I/O, and in-memory formatting.Comment
5. Templates in Depth. (Description)
6. STL Algorithms. (Description)
7. STL Containers & Iterators (Description)
Part 3: Special Topics
8. Run-time type identification. Run-time type identification
(RTTI) lets you find the exact type of an object when you only have
a pointer or reference to the base type. Normally, youll want to
intentionally ignore the exact type of an object and let the
virtual function mechanism implement the correct behavior for that
type. But occasionally it is very helpful to know the exact type of
an object for which you only have a base pointer; often this
information allows you to perform a special-case operation more
efficiently. This chapter explains what RTTI is for and how to use
it. Comment
9. Multiple inheritance. This sounds simple at first: A new
class is inherited from more than one existing class. However, you
can end up with ambiguities and multiple copies of base-class
objects. That problem is solved with virtual base classes, but the
bigger issue remains: When do you use it? Multiple inheritance is
only essential when you need to manipulate an object through more
than one common base class. This chapter explains the syntax for
multiple inheritance, and shows alternative approaches in
particular, how templates solve one common problem. The use of
multiple inheritance to repair a damaged class interface is
demonstrated as a genuinely valuable use of this
feature.Comment
10. Design Patterns.
11. Concurrent Programming.
Exercises
We have discovered that simple exercises are exceptionally
useful during a seminar to complete a students understanding, so
youll find a set at the end of each chapter.Comment
These are fairly simple, so they can be finished in a reasonable
amount of time in a classroom situation while the instructor
observes, making sure all the students are absorbing the material.
Some exercises are a bit more challenging to keep advanced students
entertained. Theyre all designed to be solved in a short time and
are only there to test and polish your knowledge rather than
present major challenges (presumably, youll find those on your own
or more likely theyll find you).Comment
Exercise solutions
Solutions to exercises can be found in the electronic document
The C++ Annotated Solution Guide, Volume 2, available for a small
fee from www.MindView.net. [[ Note this is not yet available
]]Comment
Source code
The source code for this book is copyrighted freeware,
distributed via the web site http://www.MindView.net. The copyright
prevents you from republishing the code in print media without
permission.Comment
In the starting directory where you unpacked the code you will
find the following copyright notice:Comment
//:! :CopyRight.txt
Copyright (c) MindView, Inc., 2002
Source code file from the book
"Thinking in C++, 2nd Edition, Volume 2."
All rights reserved EXCEPT as allowed by the
following statements: You can freely use this file
for your own work (personal or commercial),
including modifications and distribution in
executable form only. Permission is granted to use
this file in classroom situations, including its
use in presentation materials, as long as the book
"Thinking in C++" is cited as the source.
Except in classroom situations, you cannot copy
and distribute this code; instead, the sole
distribution point is http://www.MindView.net
(and official mirror sites) where it is
freely available. You cannot remove this
copyright and notice. You cannot distribute
modified versions of the source code in this
package. You cannot use this file in printed
media without the express permission of the
author. Bruce Eckel makes no representation about
the suitability of this software for any purpose.
It is provided "as is" without express or implied
warranty of any kind, including any implied
warranty of merchantability, fitness for a
particular purpose or non-infringement. The entire
risk as to the quality and performance of the
software is with you. Bruce Eckel and the
publisher shall not be liable for any damages
suffered by you or any third party as a result of
using or distributing software. In no event will
Bruce Eckel or the publisher be liable for any
lost revenue, profit, or data, or for direct,
indirect, special, consequential, incidental, or
punitive damages, however caused and regardless of
the theory of liability, arising out of the use of
or inability to use software, even if Bruce Eckel
and the publisher have been advised of the
possibility of such damages. Should the software
prove defective, you assume the cost of all
necessary servicing, repair, or correction. If you
think you've found an error, please submit the
correction using the form you will find at
www.MindView.net. (Please use the same
form for non-code errors found in the book.)
///:~
You may use the code in your projects and in the classroom as
long as the copyright notice is retained. Comment
Language standards
Throughout this book, when referring to conformance to the
ANSI/ISO C standard, we will generally just say Cxe "standard:
Standard C"
xe "C: Standard C". Only if it is necessary to distinguish
between Standard C and older, pre-Standard versions of C will we
make the distinction. Comment
At this writing the ANSI/ISO C++ committee xe "ANSI/ISO C++
committee"
xe "C++: ANSI/ISO C++ committee"
xe "committee, ANSI/ISO C++"was finished working on the
language. Thus, we will use the term Standard C++xe "standard:
Standard C++"
xe "C++: Standard C++" to refer to the standardized language. If
we simply refer to C++ you should assume we mean Standard C++.
Comment
Language support
Your compiler may not support all the features discussed in this
book, especially if you dont have the newest version of your
compiler. Implementing a language like C++ is a Herculean task, and
you can expect that the features will appear in pieces rather than
all at once. But if you attempt one of the examples in the book and
get a lot of errors from the compiler, its not necessarily a bug in
the code or the compiler it may simply not be implemented in your
particular compiler yet. Comment
Seminars, CD-ROMs & consulting
Bruce Eckels company, MindView, Inc., provides public hands-on
training seminars based on the material in this book, and also for
advanced topics. Selected material from each chapter represents a
lesson, which is followed by a monitored exercise period so each
student receives personal attention. We also provide on-site
training, consulting, mentoring, and design & code
walkthroughs. Information and sign-up forms for upcoming seminars
and other contact information can be found at
http://www.MindView.net. Comment
Errors
xe "book errors, reporting"
xe "error: reporting errors in book"
xe "reporting errors in book"No matter how many tricks a writer
uses to detect errors, some always creep in and these often leap
off the page for a fresh reader. If you discover anything you
believe to be an error, please use the feedback system built into
the electronic version of this book, which you will find at
http://www.MindView.net. The feedback system uses unique
identifiers on the paragraphs in the book, so you should click on
the identifier next to the paragraph that you wish to comment on.
Your help is appreciated. Comment
About the cover
The cover artwork was painted by Larry OBriens wife, Tina Jensen
(yes, the Larry OBrien who was the editor of Software Development
Magazine for so many years, and who is the primary author of
Thinking in C#). Not only are the pictures beautiful, but they are
excellent suggestions of polymorphism. The idea for using these
images came from Daniel Will-Harris, the cover designer
(www.Will-Harris.com), working with Bruce Eckel.
Acknowledgements
Volume 2 of this book languished in a half-completed state for a
long time while Bruce got distracted with other things, notably
Java, Design Patterns and especially Python (see www.Python.org).
If Chuck hadnt been willing (foolishly, he has sometimes thought)
to finish the other half, this book almost certainly wouldnt have
happened. There arent that many people whom Bruce would have felt
comfortable entrusting this book to. Chucks penchant for precision,
correctness and clear explanation is what has made this book as
good as it is.
Jamie King acted as an intern during the completion of this
book. He has been instrumental in making sure the book got
finished, not only by providing feedback for Chuck, but especially
because of his relentless questioning and picking of every single
possible nit that he didnt completely understand. If your questions
are answered by this book, its probably because Jamie asked them
first. Jamie also created many of the exercises at the end of each
chapter.
The ideas and understanding in this book have come from many
other sources, as well: friends like Andrea Provaglio, Dan Saks,
Scott Meyers, Charles Petzold, and Michael Wilk; pioneers of the
language like Bjarne Stroustrup, Andrew Koenig, and Rob Murray;
members of the C++ Standards Committee like Nathan Myers (who was
particularly helpful and generous with his insights), Herb Sutter,
PJ Plauger, Pete Becker, Kevlin Henney, David Abrahams, Tom Plum,
Reg Charney, Tom Penello, Sam Druker, and Uwe Steinmueller; people
who have spoken in the C++ track at the Software Development
Conference (which Bruce created and developed, and Chuck spoke in);
and very often students in seminars, who ask the questions we need
to hear in order to make the material clearer. Comment
The book design, cover design, and cover photo were created by
Bruces friend Daniel Will-Harris, noted author and designer, who
used to play with rub-on letters in junior high school while he
awaited the invention of computers and desktop publishing. However,
we produced the camera-ready pages ourselves, so the typesetting
errors are ours. Microsoft Word XP was used to write the book and
to create camera-ready pages. The body typeface is Georgia and the
headlines are in Verdana. Comment
We also wish to thank the generous professionals at the Edison
Design Group and Dinkumware, Ltd., for giving us complimentary
copies of their compiler and library (respectively). Without their
assistance some of the examples in this book could not have been
tested.
A special thanks to all our teachers, and all our students (who
are our teachers as well).
Evan Cofsky ([email protected]) provided all sorts of
assistance on the server as well as development of programs in his
now-favorite language, Python. Sharlynn Cobaugh and Paula Steuer
were instrumental assistants, preventing Bruce from being washed
away in a flood of projects.
Dawn McGee provided much-appreciated inspiration and enthusiasm
during this project. The supporting cast of friends includes, but
is not limited to: Mark Western, Gen Kiyooka, Kraig Brockschmidt,
Zack Urlocker, Andrew Binstock, Neil Rubenking, Steve Sinofsky, JD
Hildebrandt, Brian McElhinney, Brinkley Barr, Larry OBrien, Bill
Gates at Midnight Engineering Magazine, Larry Constantine &
Lucy Lockwood, Tom Keffer, Greg Perry, Dan Putterman, Christi
Westphal, Gene Wang, Dave Mayer, David Intersimone, Claire Sawyers,
The Italians (Andrea Provaglio, Laura Fallai, Marco Cantu, Corrado,
Ilsa and Christina Giustozzi), Chris & Laura Strand, The
Almquists, Brad Jerbic, John Kruth & Marilyn Cvitanic, Holly
Payne (yes, the famous novelist!), Mark Mabry, The Robbins
Families, The Moelter Families (& the McMillans), The Wilks,
Dave Stoner, Laurie Adams, The Cranstons, Larry Fogg, Mike &
Karen Sequeira, Gary Entsminger & Allison Brody, Chester
Andersen, Joe Lordi, Dave & Brenda Bartlett, The Rentschlers,
The Sudeks, Lynn & Todd, and their families. And of course, Mom
& Dad.
Part 1: Building Stable Systems
1: Exception handling
Improving error recoveryxe "error: recovery" is one of the most
powerful ways you can increase the robustness of your code.
Unfortunately, its almost accepted practice to ignore error
conditions, as if were in a state of denial about errors. One
reason, no doubt, is the tediousness and code bloat of checking for
many errors. For example, printf()xe "printf(): error code" returns
the number of characters that were successfully printed, but
virtually no one checks this value. The proliferation of code alone
would be disgusting, not to mention the difficulty it would add in
reading the code. Comment
The problem with Cs approach to error handling could be thought
of as couplingthe user of a function must tie the error-handling
code so closely to that function that it becomes too ungainly and
awkward to use. Comment
One of the major features in C++ is exception handling, which is
a better way of thinking about and handling errors. With exception
handlingxe "exception handling" the following statements apply:
Comment
7. Error-handling code is not nearly so tedious to write, and it
doesn't become mixed up with your "normal" code. You write the code
you want to happen; later in a separate section you write the code
to cope with the problems. If you make multiple calls to a
function, you handle the errors from that function once, in one
place.
8. Errors cannot be ignored. If a function needs to send an
error message to the caller of that function, it throws an object
representing that error out of the function. If the caller doesnt
catch the error and handle it, it goes to the next enclosing
dynamic scope, and so on until the error is either caught or the
program terminates because there was no handler to catch that type
of exception.
This chapter examines Cs approach to error handling (such as it
is), discusses why it did not work well for C, and explains why it
wont work at all for C++. This chapter also covers try, throw, and
catch, the C++ keywords that support exception handling.
Comment
Error handling in C
xe "error: error handling in C"
xe "C: error handling in C"In most of the examples in these
volumes, we use assert() as it was intended: for debugging during
development with code that can be disabled with #define NDEBUG for
the shipping product. Runtime error checking uses the require.h
functions (assure( ) and require( )) developed in Chapter 9 in
Volume 1. These functions are a convenient way to say, Theres a
problem here youll probably want to handle with some more
sophisticated code, but you dont need to be distracted by it in
this example. The require.h functions might be enough for small
programs, but for complicated products you might need to write more
sophisticated error-handling code. Comment
Error handling is quite straightforward in situations in which
you know exactly what to do because you have all the necessary
information in that context. Of course, you just handle the error
at that point. Comment
The problem occurs when you dont have enough information in that
context, and you need to pass the error information into a
different context where that information does exist. In C, you can
handle this situation using three approaches: Comment
9. Return error information from the function or, if the return
value cannot be used this way, set a global error condition flag.
(Standard C provides errno xe "errno"and perror()xe "perror()" to
support this.) As mentioned earlier, the programmer is likely to
ignore the error information because tedious and obfuscating error
checking must occur with each function call. In addition, returning
from a function that hits an exceptional condition might not make
sense.
10. Use the little-known Standard C library signal-handling
system, implemented with the signal()xe "signal()" function (to
determine what happens when the event occurs) and raise()xe
"raise()" (to generate an event). Again, this approach involves
high coupling because it requires the user of any library that
generates signals to understand and install the appropriate
signal-handling mechanism; also in large projects the signal
numbers from different libraries might clash.
11. Use the nonlocal gotoxe "non-local goto: setjmp() and
longjmp()"
xe "goto: non-local goto, setjmp() and longjmp()" functions in
the Standard C library: setjmp()xe "setjmp()" and longjmp()xe
"longjmp()". With setjmp() you save a known good state in the
program, and if you get into trouble, longjmp() will restore that
state. Again, there is high coupling between the place where the
state is stored and the place where the error occurs.
When considering error-handling schemes with C++, theres an
additional very critical problem: The C techniques of signals and
setjmp()/longjmp() do not call destructors, so objects arent
properly cleaned up. (In fact, if longjmp() jumps past the end of a
scope where destructors should be called, the behavior of the
program is undefined.) This makes it virtually impossible to
effectively recover from an exceptional condition because youll
always leave objects behind that havent been cleaned up and that
can no longer be accessed. The following example demonstrates this
with setjmp/longjmp: Comment
//: C01:Nonlocal.cpp
// setjmp() & longjmp()
#include
#include
using namespace std;
class Rainbow {
public:
Rainbow() { cout osptr = osptr;
nPass = nFail = 0;
}
inline long Test::getNumPassed() const {
return nPass;
}
inline long Test::getNumFailed() const {
return nFail;
}
inline const ostream* Test::getStream() const {
return osptr;
}
inline void Test::setStream(ostream* osptr) {
this->osptr = osptr;
}
inline void Test::succeed_() {
++nPass;
}
inline void Test::reset() {
nPass = nFail = 0;
}
} // namespace TestSuite
#endif // TEST_H ///:~
There are three virtual functions in the Test class:
A virtual destructor
The function reset()
The pure virtual function run()
As explained in Volume 1, it is an error to delete a derived
heap object through a base pointer unless the base class has a
virtual destructor. Any class intended to be a base class (usually
evidenced by the presence of at least one other virtual function)
should have a virtual destructor. The default implementation of the
Test::reset() resets the success and failure counters to zero. You
might want to override this function to reset the state of the data
in your derived test object; just be sure to call Test::reset()
explicitly in your override so that the counters are reset. The
Test::run() member function is pure virtual, of course, since you
are required to override it in your derived class. Comment
The test_() and fail_() macros can include file name and line
number information available from the preprocessor. We originally
omitted the trailing underscores in the names, but the original
fail() macro collided with ios::fail(), causing all kinds of
compiler errors. Comment
Here is the implementation of Test:
//: TestSuite:Test.cpp {O}
#include "Test.h"
#include
#include // Note: Visual C++ requires /GR""
using namespace std;
using namespace TestSuite;
void Test::do_test(bool cond,
const std::string& lbl, const char* fname,
long lineno) {
if (!cond)
do_fail(lbl, fname, lineno);
else
succeed_();
}
void Test::do_fail(const std::string& lbl,
const char* fname, long lineno) {
++nFail;
if (osptr) {
*osptr '.
size_t rightPos = s.find('>');
if (rightPos != string::npos) {
inTag = false;
s.erase(0, rightPos + 1);
}
else {
done = true;
s.erase();
}
}
else {
// Look for start of tag:
size_t leftPos = s.find('');
if (rightPos == string::npos) {
inTag = done = true;
s.erase(leftPos);
}
else
s.erase(leftPos, rightPos - leftPos + 1);
}
else
done = true;
}
}
// Remove all special HTML characters
replaceAll(s, "
