使用erase()成员函数删除字符串中的字符是简单而有效的
//: C03:HTMLStripper.cpp {RunByHand}
// From "Thinking in C++, Volume 2", by Bruce Eckel & Chuck Allison.
// (c) 1995-2004 MindView, Inc. All Rights Reserved.
// See source code use permissions stated in the file 'License.txt',
// distributed with the code package available at www.MindView.net.
//{L} ReplaceAll
// Filter to remove html tags and markers.
#include <cassert>
#include <cmath>
#include <cstddef>
#include <fstream>
#include <iostream>
#include <string>
#include "ReplaceAll.h"
#include "../require.h"
using namespace std;
string& stripHTMLTags(string& s) {
static bool inTag = false;
bool done = false;
while(!done) {
if(inTag) {
// The previous line started an HTML tag
// but didn't finish. Must search for '>'.
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(leftPos != string::npos) {
// See if tag close is in this line:
size_t rightPos = 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, "<", "<");
replaceAll(s, ">", ">");
replaceAll(s, "&", "&");
replaceAll(s, " ", " ");
// Etc...
return s;
}
int main(int argc, char* argv[]) {
requireArgs(argc, 1,
"usage: HTMLStripper InputFile");
ifstream in(argv[1]);
assure(in, argv[1]);
string s;
while(getline(in, s))
if(!stripHTMLTags(s).empty())
cout << s << endl;
getchar();
} ///:~这个例子甚至能够删除跨越多行的HTML标记
归功于静态标志inTag,一旦发现了开始标记，此逻辑标志就会设为
true,无论相应的结束标记是否与这个开始标记在同一行
命令行输出 没有参数
usage: HTMLStripper InputFile
命令行输出 有参数 HTMLStripper.cpp
//: C03:HTMLStripper.cpp {RunByHand}
// From "Thinking in C++, Volume 2", by Bruce Eckel & Chuck Allison.
// (c) 1995-2004 MindView, Inc. All Rights Reserved.
// See source code use permissions stated in the file 'License.txt',
// distributed with the code package available at www.MindView.net.
//{L} ReplaceAll
// Filter to remove html tags and markers.
#include
#include
#include
#include
#include
#include
#include "ReplaceAll.h"
#include "../require.h"
using namespace std;
string& stripHTMLTags(string& s) {
static bool inTag = false;
bool done = false;
while(!done) {
if(inTag) {
// The previous line started an HTML tag
// but didn't finish. Must search for '>'.
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, "<", "
");
replaceAll(s, "&", "&");
replaceAll(s, " ", " ");
// Etc...
return s;
}
int main(int argc, char* argv[]) {
requireArgs(argc, 1,
"usage: HTMLStripper InputFile");
ifstream in(argv[1]);
assure(in, argv[1]);
string s;
while(getline(in, s))
if(!stripHTMLTags(s).empty())
cout
参数输入AppendixC.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<!--
This document was converted from RTF source:
By rtftohtml 4.19
See http://www.sunpack.com/RTF
Filename:TIC2Vone.rtf
Application Directory:C:\TOOLS\RTF2HTML\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:09/27/2001
Translation Time:05:26:08
Translation Platform:Win32
Number of Output files:22
This File:AppendixC.html
SplitDepth=1
SkipNavPanel=1
SkipLeadingToc=1
SkipTrailingToc=1
GenContents=1
GenFrames=1
GenIndex=1
-->
<HEAD lang="en"><META http-equiv="Content-Type" content="text/html">
<TITLE>C: Recommended Reading</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF"><DIV ALIGN="CENTER">
<a href="http://www.MindView.net">
<img src="mindview-head.gif" alt="MindView Inc." BORDER = "0"></a>
<CENTER>
<FONT FACE="Verdana" size = "-1">
[ <a href="README-HTML.txt">Viewing Hints</a> ]
[ <a href="http://www.mindview.net/CPPServices/SolutionGuide.html">Exercise Solutions</a> ]
[ <a href="http://www.mindview.net/ThinkingInCPP2e.html">Volume 2</a> ]
[ <a href="http://www.mindview.net/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/CPPServices/#PublicSeminars">Seminars</a> ]
[ <a href="http://www.mindview.net/CPPServices/#SeminarsOnCD">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/CPPServices/#ConsultingServices">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana">
Thinking in C++, 2nd ed. Volume 1</FONT></H2></FONT>
<H3><FONT FACE="Verdana">©2000 by Bruce Eckel</FONT></H3></FONT>
<FONT FACE="Verdana" size = "-1">
[ <a href="AppendixB.html">Previous Chapter</a> ]
[ <a href="Contents.html">Table of Contents</a> ]
[ <a href="DocIndex.html">Index</a> ]
</FONT>
</CENTER>
</P></DIV><A NAME="_Toc472655068"></A><A NAME="Heading487"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
C: Recommended Reading</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=4>Resources for further
study.</FONT><A NAME="RecommendedReading"></A><A NAME="_Toc472655069"></A><BR></P></DIV>
<A NAME="Heading488"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
C<BR><A NAME="Index2768"></A><A NAME="Index2769"></A></H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Thinking in C: Foundations for Java
& C++</B>, by <A NAME="Index2770"></A>Chuck Allison (a MindView, Inc.
Seminar-on-CD ROM, ©2000, bound into the back of this book and also
available at <I>www.BruceEckel.com</I>). This is a course including lectures and
slides in the foundations of the C Language to prepare you to learn Java or C++.
This is not an exhaustive course in C; only the necessities for moving on to the
other languages are included. Additional language-specific sections introduce
features for the C++ or Java programmer-to-be. Recommended prerequisite: some
experience with a high-level programming language, such as Pascal, BASIC,
Fortran, or LISP (it’s possible to struggle through the CD without this
background, but the course isn’t designed to be an introduction to the
basics of programming). </FONT><A NAME="_Toc472655070"></A><BR></P></DIV>
<A NAME="Heading489"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
General C++</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>The C++ Programming Language,
3<SUP>rd</SUP> edition</B>, by <A NAME="Index2771"></A>Bjarne Stroustrup
(Addison-Wesley 1997). To some degree, the goal of the book that you’re
currently holding is to allow you to use Bjarne’s book as a reference.
Since his book contains the description of the language by the author of that
language, it’s typically the place where you’ll go to resolve any
uncertainties about what C++ is or isn’t supposed to do. When you get the
knack of the language and are ready to get serious, you’ll need
it.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>C++ Primer, 3<SUP>rd</SUP>
Edition</B>, by <A NAME="Index2772"></A>Stanley Lippman and
<A NAME="Index2773"></A>Josee Lajoie (Addison-Wesley 1998). Not that much of a
primer anymore; it’s evolved into a thick book filled with lots of detail,
and the one that I reach for along with Stroustrup’s when trying to
resolve an issue. <I>Thinking in C++</I> should provide a basis for
understanding the <I>C++ Primer </I>as well as Stroustrup’s
book.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>C & C++ Code Capsules</B>, by
<A NAME="Index2774"></A>Chuck Allison (Prentice-Hall, 1998). This book assumes
that you already know C and C++, and covers some of the issues that you may be
rusty on, or that you may not have gotten right the first time. This book fills
in C gaps as well as C++ gaps.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>The C++ Standard</B>. This is the
document that the committee worked so hard on for all those years. This is
<I>not</I> free, unfortunately. But at least you can buy the electronic form in
PDF for only $18 at
<I>www.cssinfo.com</I>.</FONT><A NAME="_Toc472655071"></A><BR></P></DIV>
<A NAME="Heading490"></A><FONT FACE = "Verdana"><H3 ALIGN="LEFT">
My own list of books </H3></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Listed in order of publication. Not all
of these are currently available.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Computer Interfacing with Pascal &
C</B> (Self-published via the Eisys imprint, 1988. Only available via
<I>www.BruceEckel.com</I>). An introduction to electronics from back when CP/M
was still king and DOS was an upstart. I used high-level languages and often the
parallel port of the computer to drive various electronic projects. Adapted from
my columns in the first and best magazine I wrote for, <I>Micro Cornucopia
</I>(To paraphrase Larry O’Brien, long-time editor of <I>Software
Development Magazine</I>: the best computer magazine ever published – they
even had plans for building a robot in a flower pot!) Alas, Micro C became lost
long before the Internet appeared. Creating this book was an extremely
satisfying publishing experience.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Using C++</B> (Osborne/McGraw-Hill
1989). One of the first books out on C++. This is out of print and replaced by
its second edition, the renamed <B>C++ Inside & Out</B>.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>C++ Inside & Out</B>
(Osborne/McGraw-Hill 1993). As noted, actually the 2<SUP>nd</SUP> edition of
<B>Using C++</B>. The C++ in this book is reasonably accurate, but it's circa
1992 and <I>Thinking in C++</I> is intended to replace it. You can find out more
about this book and download the source code at
<I>www.BruceEckel.com</I>.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Thinking in C++, 1<SUP>st</SUP>
edition</B> (Prentice-Hall 1995). </FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Black Belt C++, the Master’s
Collection</B>, Bruce Eckel, editor (M&T Books 1994). Out of print. A
collection of chapters by various C++ luminaries based on their presentations in
the C++ track at the Software Development Conference, which I chaired. The cover
on this book stimulated me to gain control over all future cover
designs.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Thinking in Java</B>, 2<SUP>nd</SUP>
edition (Prentice-Hall, 2000). The first edition of this book won the
<I>Software Development Magazine </I>Productivity Award and the <I>Java
Developer’s Journal </I>Editor’s Choice Award in 1999. Downloadable
from <I>www.BruceEckel.com</I>.</FONT><A NAME="_Toc472655072"></A><BR></P></DIV>
<A NAME="Heading491"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Depth & dark corners</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">These books go more deeply into language
topics, and help you avoid the typical pitfalls inherent in developing C++
programs.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Effective C++</B> (2<SUP>nd</SUP>
Edition, Addison-Wesley 1998) and <B>More Effective C++</B> (Addison-Wesley
1996), by <A NAME="Index2775"></A>Scott Meyers. The classic, must-have texts for
serious problem-solving and code design in C++. I’ve tried to capture and
express many of the concepts from these books in <I>Thinking in C++</I>, but I
don’t fool myself in thinking that I’ve succeeded. If you spend any
serious time with C++ you’ll end up with these books. Also available on CD
ROM. </FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Ruminations on C++</B>, by
<A NAME="Index2776"></A>Andrew Koenig and <A NAME="Index2777"></A>Barbara Moo
(Addison-Wesley, 1996). Andrew worked directly with Stroustrup on many aspects
of the C++ language and is an extremely reliable authority. I’ve also
found the incisiveness of his insights to be refreshing, and have learned much
from him, both in print and in person, over the years.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Large-Scale C++ Software Design</B>,
by <A NAME="Index2778"></A>John Lakos<B> </B>(Addison-Wesley, 1996). Covers
issues and answers questions you will encounter during the creation of big
projects, but often smaller ones as well.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>C++ Gems</B>, Stan Lippman, editor
(SIGS publications, 1996). A selection of articles from <I>The C++
Report</I>.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>The Design & Evolution of C++</B>,
by <A NAME="Index2779"></A>Bjarne Stroustrup (Addison-Wesley 1994). Insights
from the inventor of C++ about why he made various design decisions. Not
essential, but interesting.</FONT><A NAME="_Toc472655073"></A><BR></P></DIV>
<A NAME="Heading492"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Analysis & design<BR><A NAME="Index2780"></A><A NAME="Index2781"></A></H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Extreme Programming Explained </B>by
<A NAME="Index2782"></A>Kent Beck (Addison-Wesley 2000). I <I>love</I> this
book. Yes, I tend to take a radical approach to things but I've always felt that
there could be a much different, much better program development process, and I
think XP comes pretty darn close. The only book that has had a similar impact on
me was <I>PeopleWare </I>(described below), which talks primarily about the
environment and dealing with corporate culture. <I>Extreme Programming
Explained</I> talks about programming, and turns most things, even recent
“findings,” on their ear. They even go so far as to say that
pictures are OK as long as you don’t spend too much time on them and are
willing to throw them away. (You’ll notice that this book does <I>not
</I>have the “UML stamp of approval” on its cover.) I could see
deciding whether to work for a company based solely on whether they used XP.
Small book, small chapters, effortless to read, exciting to think about. You
start imagining yourself working in such an atmosphere and it brings visions of
a whole new world.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><A NAME="Index2783"></A><A NAME="Index2784"></A><FONT FACE="Georgia"><B>UML
Distilled</B> by <A NAME="Index2785"></A>Martin Fowler (2<SUP>nd</SUP> edition,
Addison-Wesley, 2000). When you first encounter UML, it is daunting because
there are so many diagrams and details. According to Fowler, most of this stuff
is unnecessary so he cuts through to the essentials. For most projects, you only
need to know a few diagramming tools, and Fowler’s goal is to come up with
a good design rather than worry about all the artifacts of getting there. A
nice, thin, readable book; the first one you should get if you need to
understand UML.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>The Unified Software Development
Process</B> by <A NAME="Index2786"></A>Ivar Jacobsen, Grady
Booch<A NAME="Index2787"></A>, and <A NAME="Index2788"></A>James Rumbaugh
(Addison-Wesley 1999). I went in fully prepared to dislike this book. It seemed
to have all the makings of a boring college text. I was pleasantly surprised
– only pockets of the book contain explanations that seem as if those
concepts aren’t clear to the authors. The bulk of the book is not only
clear, but enjoyable. And best of all, the process makes a lot of practical
sense. It’s not Extreme Programming (and does not have their clarity about
testing) but it’s also part of the UML juggernaut – even if you
can’t get XP adopted, most people have climbed aboard the “UML is
good” bandwagon (regardless of their <I>actual</I> level of experience
with it) and so you can probably get it adopted. I think this book should be the
flagship of UML, and the one you can read after Fowler’s <I>UML
Distilled</I> when you want more detail.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Before you choose any method, it’s
helpful to gain perspective from those who are not trying to sell one.
It’s easy to adopt a method without really understanding what you want out
of it or what it will do for you. Others are using it, which seems a compelling
reason. However, humans have a strange little psychological quirk: If they want
to believe something will solve their problems, they’ll try it. (This is
experimentation, which is good.) But if it doesn’t solve their problems,
they may redouble their efforts and begin to announce loudly what a great thing
they’ve discovered. (This is denial, which is not good.) The assumption
here may be that if you can get other people in the same boat, you won’t
be lonely, even if it’s going nowhere (or sinking).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">This is not to suggest that all
methodologies go nowhere, but that you should be armed to the teeth with mental
tools that help you stay in experimentation mode (“It’s not working;
let’s try something else”) and out of denial mode (“No,
that’s not really a problem. Everything’s wonderful, we don’t
need to change”). I think the following books, read <I>before</I> you
choose a method, will provide you with these tools.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Software Creativity</B>, by Robert
Glass<A NAME="Index2789"></A> (Prentice-Hall, 1995). This is the best book
I’ve seen that discusses <I>perspective</I> on the whole methodology
issue. It’s a collection of short essays and papers that Glass has written
and sometimes acquired (P.J. Plauger<A NAME="Index2790"></A> is one
contributor), reflecting his many years of thinking and study on the subject.
They’re entertaining and only long enough to say what’s necessary;
he doesn’t ramble and bore you. He’s not just blowing smoke, either;
there are hundreds of references to other papers and studies. All programmers
and managers should read this book before wading into the methodology
mire.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Software Runaways: Monumental Software
Disasters</B>, by Robert Glass (Prentice-Hall 1997). The great thing about this
book is that it brings to the forefront what we don’t talk about: how many
projects not only fail, but fail spectacularly. I find that most of us still
think “That can’t happen to me” (or “That can’t
happen <I>again</I>”) and I think this puts us at a disadvantage. By
keeping in mind that things can always go wrong, you’re in a much better
position to make them go right.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Object Lessons</B> by Tom
Love<A NAME="Index2791"></A> (SIGS Books, 1993). Another good
“perspective” book.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Peopleware</B>, by Tom
Demarco<A NAME="Index2792"></A> and Timothy Lister<A NAME="Index2793"></A>
(Dorset House, 2<SUP>nd</SUP> edition 1999). Although they have backgrounds in
software development, this book is about projects and teams in general. But the
focus is on the <I>people</I> and their needs rather than the technology and its
needs. They talk about creating an environment where people will be happy and
productive, rather than deciding what rules those people should follow to be
adequate components of a machine. This latter attitude, I think, is the biggest
contributor to programmers smiling and nodding when XYZ method is adopted and
then quietly doing whatever they’ve always done.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><B>Complexity</B>, by M. Mitchell
Waldrop<A NAME="Index2794"></A> (Simon & Schuster, 1992). This chronicles
the coming together of a group of scientists from different disciplines in Santa
Fe, New Mexico, to discuss real problems that the individual disciplines
couldn’t solve (the stock market in economics, the initial formation of
life in biology, why people do what they do in sociology, etc.). By crossing
physics, economics, chemistry, math, computer science, sociology, and others, a
multidisciplinary approach to these problems is developing. But more
importantly, a different way of <I>thinking</I> about these ultra-complex
problems is emerging: Away from mathematical determinism and the illusion that
you can write an equation that predicts all behavior and toward first
<I>observing </I>and looking for a pattern and trying to emulate that pattern by
any means possible. (The book chronicles, for example, the emergence of genetic
algorithms.) This kind of thinking, I believe, is useful as we observe ways to
manage more and more complex software projects.</FONT><BR></P></DIV>
<DIV ALIGN="CENTER">
<FONT FACE="Verdana" size = "-1">
[ <a href="AppendixB.html">Previous Chapter</a> ]
[ <a href="Contents.html">Table of Contents</a> ]
[ <a href="DocIndex.html">Index</a> ]
</FONT>
<BR>
Last Update:09/27/2001</P></DIV>
</BODY>
</HTML>输出
[ Exercise Solutions ]
[ Volume 2 ]
[ Free Newsletter ]
[ Seminars ]
[ Seminars on CD ROM ]
[ Consulting ]
Thinking in C++, 2nd ed. Volume 1
©2000 by Bruce Eckel
[ Previous Chapter ]
[ Table of Contents ]
[ Index ]
C: Recommended Reading
Resources for further
study.
C
Thinking in C: Foundations for Java
& C++, by Chuck Allison (a MindView, Inc.
Seminar-on-CD ROM, ©2000, bound into the back of this book and also
available at www.BruceEckel.com). This is a course including lectures and
slides in the foundations of the C Language to prepare you to learn Java or C++.
This is not an exhaustive course in C; only the necessities for moving on to the
other languages are included. Additional language-specific sections introduce
features for the C++ or Java programmer-to-be. Recommended prerequisite: some
experience with a high-level programming language, such as Pascal, BASIC,
Fortran, or LISP (it’s possible to struggle through the CD without this
background, but the course isn’t designed to be an introduction to the
basics of programming).
General C++
The C++ Programming Language,
3rd edition, by Bjarne Stroustrup
(Addison-Wesley 1997). To some degree, the goal of the book that you’re
currently holding is to allow you to use Bjarne’s book as a reference.
Since his book contains the description of the language by the author of that
language, it’s typically the place where you’ll go to resolve any
uncertainties about what C++ is or isn’t supposed to do. When you get the
knack of the language and are ready to get serious, you’ll need
it.
C++ Primer, 3rd
Edition, by Stanley Lippman and
Josee Lajoie (Addison-Wesley 1998). Not that much of a
primer anymore; it’s evolved into a thick book filled with lots of detail,
and the one that I reach for along with Stroustrup’s when trying to
resolve an issue. Thinking in C++ should provide a basis for
understanding the C++ Primer as well as Stroustrup’s
book.
C & C++ Code Capsules, by
Chuck Allison (Prentice-Hall, 1998). This book assumes
that you already know C and C++, and covers some of the issues that you may be
rusty on, or that you may not have gotten right the first time. This book fills
in C gaps as well as C++ gaps.
The C++ Standard. This is the
document that the committee worked so hard on for all those years. This is
not free, unfortunately. But at least you can buy the electronic form in
PDF for only $18 at
www.cssinfo.com.
My own list of books
Listed in order of publication. Not all
of these are currently available.
Computer Interfacing with Pascal &
C (Self-published via the Eisys imprint, 1988. Only available via
www.BruceEckel.com). An introduction to electronics from back when CP/M
was still king and DOS was an upstart. I used high-level languages and often the
parallel port of the computer to drive various electronic projects. Adapted from
my columns in the first and best magazine I wrote for, Micro Cornucopia
(To paraphrase Larry O’Brien, long-time editor of Software
Development Magazine: the best computer magazine ever published – they
even had plans for building a robot in a flower pot!) Alas, Micro C became lost
long before the Internet appeared. Creating this book was an extremely
satisfying publishing experience.
Using C++ (Osborne/McGraw-Hill
1989). One of the first books out on C++. This is out of print and replaced by
its second edition, the renamed C++ Inside & Out.
C++ Inside & Out
(Osborne/McGraw-Hill 1993). As noted, actually the 2nd edition of
Using C++. The C++ in this book is reasonably accurate, but it's circa
1992 and Thinking in C++ is intended to replace it. You can find out more
about this book and download the source code at
www.BruceEckel.com.
Thinking in C++, 1st
edition (Prentice-Hall 1995).
Black Belt C++, the Master’s
Collection, Bruce Eckel, editor (M&T Books 1994). Out of print. A
collection of chapters by various C++ luminaries based on their presentations in
the C++ track at the Software Development Conference, which I chaired. The cover
on this book stimulated me to gain control over all future cover
designs.
Thinking in Java, 2nd
edition (Prentice-Hall, 2000). The first edition of this book won the
Software Development Magazine Productivity Award and the Java
Developer’s Journal Editor’s Choice Award in 1999. Downloadable
from www.BruceEckel.com.
Depth & dark corners
These books go more deeply into language
topics, and help you avoid the typical pitfalls inherent in developing C++
programs.
Effective C++ (2nd
Edition, Addison-Wesley 1998) and More Effective C++ (Addison-Wesley
1996), by Scott Meyers. The classic, must-have texts for
serious problem-solving and code design in C++. I’ve tried to capture and
express many of the concepts from these books in Thinking in C++, but I
don’t fool myself in thinking that I’ve succeeded. If you spend any
serious time with C++ you’ll end up with these books. Also available on CD
ROM.
Ruminations on C++, by
Andrew Koenig and Barbara Moo
(Addison-Wesley, 1996). Andrew worked directly with Stroustrup on many aspects
of the C++ language and is an extremely reliable authority. I’ve also
found the incisiveness of his insights to be refreshing, and have learned much
from him, both in print and in person, over the years.
Large-Scale C++ Software Design,
by John Lakos (Addison-Wesley, 1996). Covers
issues and answers questions you will encounter during the creation of big
projects, but often smaller ones as well.
C++ Gems, Stan Lippman, editor
(SIGS publications, 1996). A selection of articles from The C++
Report.
The Design & Evolution of C++,
by Bjarne Stroustrup (Addison-Wesley 1994). Insights
from the inventor of C++ about why he made various design decisions. Not
essential, but interesting.
Analysis & design
Extreme Programming Explained by
Kent Beck (Addison-Wesley 2000). I love this
book. Yes, I tend to take a radical approach to things but I've always felt that
there could be a much different, much better program development process, and I
think XP comes pretty darn close. The only book that has had a similar impact on
me was PeopleWare (described below), which talks primarily about the
environment and dealing with corporate culture. Extreme Programming
Explained talks about programming, and turns most things, even recent
“findings,” on their ear. They even go so far as to say that
pictures are OK as long as you don’t spend too much time on them and are
willing to throw them away. (You’ll notice that this book does not
have the “UML stamp of approval” on its cover.) I could see
deciding whether to work for a company based solely on whether they used XP.
Small book, small chapters, effortless to read, exciting to think about. You
start imagining yourself working in such an atmosphere and it brings visions of
a whole new world.
UML
Distilled by Martin Fowler (2nd edition,
Addison-Wesley, 2000). When you first encounter UML, it is daunting because
there are so many diagrams and details. According to Fowler, most of this stuff
is unnecessary so he cuts through to the essentials. For most projects, you only
need to know a few diagramming tools, and Fowler’s goal is to come up with
a good design rather than worry about all the artifacts of getting there. A
nice, thin, readable book; the first one you should get if you need to
understand UML.
The Unified Software Development
Process by Ivar Jacobsen, Grady
Booch, and James Rumbaugh
(Addison-Wesley 1999). I went in fully prepared to dislike this book. It seemed
to have all the makings of a boring college text. I was pleasantly surprised
– only pockets of the book contain explanations that seem as if those
concepts aren’t clear to the authors. The bulk of the book is not only
clear, but enjoyable. And best of all, the process makes a lot of practical
sense. It’s not Extreme Programming (and does not have their clarity about
testing) but it’s also part of the UML juggernaut – even if you
can’t get XP adopted, most people have climbed aboard the “UML is
good” bandwagon (regardless of their actual level of experience
with it) and so you can probably get it adopted. I think this book should be the
flagship of UML, and the one you can read after Fowler’s UML
Distilled when you want more detail.
Before you choose any method, it’s
helpful to gain perspective from those who are not trying to sell one.
It’s easy to adopt a method without really understanding what you want out
of it or what it will do for you. Others are using it, which seems a compelling
reason. However, humans have a strange little psychological quirk: If they want
to believe something will solve their problems, they’ll try it. (This is
experimentation, which is good.) But if it doesn’t solve their problems,
they may redouble their efforts and begin to announce loudly what a great thing
they’ve discovered. (This is denial, which is not good.) The assumption
here may be that if you can get other people in the same boat, you won’t
be lonely, even if it’s going nowhere (or sinking).
This is not to suggest that all
methodologies go nowhere, but that you should be armed to the teeth with mental
tools that help you stay in experimentation mode (“It’s not working;
let’s try something else”) and out of denial mode (“No,
that’s not really a problem. Everything’s wonderful, we don’t
need to change”). I think the following books, read before you
choose a method, will provide you with these tools.
Software Creativity, by Robert
Glass (Prentice-Hall, 1995). This is the best book
I’ve seen that discusses perspective on the whole methodology
issue. It’s a collection of short essays and papers that Glass has written
and sometimes acquired (P.J. Plauger is one
contributor), reflecting his many years of thinking and study on the subject.
They’re entertaining and only long enough to say what’s necessary;
he doesn’t ramble and bore you. He’s not just blowing smoke, either;
there are hundreds of references to other papers and studies. All programmers
and managers should read this book before wading into the methodology
mire.
Software Runaways: Monumental Software
Disasters, by Robert Glass (Prentice-Hall 1997). The great thing about this
book is that it brings to the forefront what we don’t talk about: how many
projects not only fail, but fail spectacularly. I find that most of us still
think “That can’t happen to me” (or “That can’t
happen again”) and I think this puts us at a disadvantage. By
keeping in mind that things can always go wrong, you’re in a much better
position to make them go right.
Object Lessons by Tom
Love (SIGS Books, 1993). Another good
“perspective” book.
Peopleware, by Tom
Demarco and Timothy Lister
(Dorset House, 2nd edition 1999). Although they have backgrounds in
software development, this book is about projects and teams in general. But the
focus is on the people and their needs rather than the technology and its
needs. They talk about creating an environment where people will be happy and
productive, rather than deciding what rules those people should follow to be
adequate components of a machine. This latter attitude, I think, is the biggest
contributor to programmers smiling and nodding when XYZ method is adopted and
then quietly doing whatever they’ve always done.
Complexity, by M. Mitchell
Waldrop (Simon & Schuster, 1992). This chronicles
the coming together of a group of scientists from different disciplines in Santa
Fe, New Mexico, to discuss real problems that the individual disciplines
couldn’t solve (the stock market in economics, the initial formation of
life in biology, why people do what they do in sociology, etc.). By crossing
physics, economics, chemistry, math, computer science, sociology, and others, a
multidisciplinary approach to these problems is developing. But more
importantly, a different way of thinking about these ultra-complex
problems is emerging: Away from mathematical determinism and the illusion that
you can write an equation that predicts all behavior and toward first
observing and looking for a pattern and trying to emulate that pattern by
any means possible. (The book chronicles, for example, the emergence of genetic
algorithms.) This kind of thinking, I believe, is useful as we observe ways to
manage more and more complex software projects.
[ Previous Chapter ]
[ Table of Contents ]
[ Index ] Last Update:09/27/2001
贴剩下的代码 ReplaceAll.h ReplaceAll.cpp
//: C03:ReplaceAll.h
// From "Thinking in C++, Volume 2", by Bruce Eckel & Chuck Allison.
// (c) 1995-2004 MindView, Inc. All Rights Reserved.
// See source code use permissions stated in the file 'License.txt',
// distributed with the code package available at www.MindView.net.
#ifndef REPLACEALL_H
#define REPLACEALL_H
#include <string>
std::string& replaceAll(std::string& context,
const std::string& from, const std::string& to);
#endif // REPLACEALL_H ///:~
//: C03:ReplaceAll.cpp {O}
// From "Thinking in C++, Volume 2", by Bruce Eckel & Chuck Allison.
// (c) 1995-2004 MindView, Inc. All Rights Reserved.
// See source code use permissions stated in the file 'License.txt',
// distributed with the code package available at www.MindView.net.
#include <cstddef>
#include "ReplaceAll.h"
using namespace std;
string& replaceAll(string& context, const string& from,
const string& to) {
size_t lookHere = 0;
size_t foundHere;
while((foundHere = context.find(from, lookHere))
!= string::npos) {
context.replace(foundHere, from.size(), to);
lookHere = foundHere + to.size();
}
return context;
} ///:~