
In this directory are build-tools---that is, programs
used to build the book.  Though build-tools are of no
direct use to the book's reader and are not distributed
with the book once the book is built, neither are they
mere optional development helpers; they are integral
parts of the book's source.  One cannot build the book
fully correctly from source without them.

Build tools in general might provide any transformation
needed during building, but these particular build-tools
(or "tool" if there is only one at the moment) serve to
add a few typical PDF features like an outline table of
contents to the book in PDF.  Such features are added
automatically (and probably better) by PDFLaTeX, but
PDFLaTeX does not coexist happily with Timothy Van
Zandt's PSTricks and Seminar packages, which the author
likes.  (There exists a PDFTricks package, but it does
not help much.)

The source is organized into several subdirectories.
This is a matter of preference.  It is not done because
the source is particularly large, but only because the
author finds it convenient to organize the source in
this way, and because there seems little real reason not
to do so.  [Too many C++ source files and headers in one
directory, alphabetically listed by ls(1), make the
author squint.]

PERIPHERAL REMARKS

The source admittedly represents the author's first
attempt himself to split a single executable's code into
several subdirectories.  For the author it is an
interesting experiment, and it is probably not done
perfectly.  The resultant Makefiles are uncomfortably
cryptic though surprisingly short [the experiment has
taught the author much about make(1)].  Automake
probably provides an alternative, but the author would
prefer to avoid Automake.  Then there are various build
systems like BJam, SCons, etc., which the author has not
tried.  Advice, references to well organized sources as
examples, and so forth would be well received.

The source has fewer comments than some sources the
author has written in the past.  Comments play a central
role in Fortran 77 and C programming, but the author has
learned from Bjarne Stroustrup regarding C++ comments
that, when an idea can be expressed in the programming
language itself, it usually should be.  Many more ideas
can be expressed cleanly in C++ than in the older
languages.

The trouble with unnecessary comments is that one
naturally tends to write a comment when one first drafts
the code fragment to which it immediately pertains,
which means that one writes most comments at a time when
the source is substantially incomplete.  Revising
earlier code fragments when one writes later code (an
extensively standard programming activity), one often
inadvertently leaves old comments incomplete,
irrelevant, inaccurate, misleading or even positively
false.  The compiler cannot help.  Experience suggests
that it were better not to have written the unnecessary
comments in the first place.  (The practice of
commenting source liberally, drilled by the first
generation of computer scientists into their students,
seems likely to go the way of source flowcharting, into
the museum of early computer-science history; they're
nice ideas, but praxis has found better ways to reach
their goals.)

