diff --git a/publications.md b/publications.md
index 1ab8908..25351e0 100644
--- a/publications.md
+++ b/publications.md
@@ -98,6 +98,8 @@ Scientists and Engineers Think They Know About Software Engineering: A
Survey*. SAND2011-2196J. Submitted to Computing in Science and
Engineering. March 2011 [[PDF](SECSESurvey-CiSEMagazineArticle_Final.pdf)]
+
+
Bartlett, Roscoe. *Teuchos C++ Memory Management Classes, Idioms, and Related
Topics: The Complete Reference (A Comprehensive Strategy for Safe and
Efficient Memory Management in C++ for High Performance
@@ -115,6 +117,8 @@ Safety Codes System Design Specification. SAND2009-3969, Sandia National
Laboratories*. September 2009 [[PDF](NEAMS_IPSC_WF_Report_FY09.pdf)] (See
sections 6.2, 7.5, 7.6, 7.7, 7.8, and C.3 all written by Roscoe Bartlett)
+
+
Bartlett, Roscoe. *Mathematical and High-Level Overview of MOOCHO: The
Multifunctional Object-Oriented arCHitecture for Optimization*. SAND2009-3969,
Sandia National Laboratories. June 2009 [[PDF](MoochoOverview.pdf)]
@@ -167,6 +171,13 @@ Bartlett, Roscoe, Bart van Bloemen Waanders, and Michael Heroux. *Vector
Reduction/Transformation Operators, ACM Transactions on Mathematical
Software*. Vol. 30, No. 1, p. 62 -85, 2004 [[PDF](RTOpTOMS2004.pdf)]
+
+
+Bartlett, Roscoe, and Lorenz Biegler. *rSQP++: An Object-Oriented Framework
+for Successive Quadratic Pogramming*. In: Biegler L.T., Heinkenschloss M.,
+Ghattas O., van Bloemen Waanders B. (eds) *Large-Scale PDE-Constrained
+Optimization*. Lecture Notes in Computational Science and Engineering, vol 30.
+Springer, Berlin, Heidelberg, 2003 [[PDF](rSQPxx_2003.pdf)]
## Presentations
diff --git a/publications/rSQPxx_2003.pdf b/publications/rSQPxx_2003.pdf
new file mode 100755
index 0000000..94927f7
Binary files /dev/null and b/publications/rSQPxx_2003.pdf differ
diff --git a/reading-list.md b/reading-list.md
index ae5de20..577b61a 100644
--- a/reading-list.md
+++ b/reading-list.md
@@ -24,36 +24,42 @@ Hopefully this reading list will help others the way it has helped me.
* [B.2) Recommended Books on the Fine Details of C++](#b2-recommended-books-on-the-fine-details-of-c)
* [B.3) Recommended Books on the History of C++ and why it has it's current form](#b3-recommended-books-on-the-history-of-c-and-why-it-has-its-current-form)
-# Background
-
-To provide some context and motivation for this reading list, I describe my
-background and experiences. When I started my Ph.D. in Chemical Engineering
-in 1996 at Carnegie Mellon University (CMU), I knew that I liked writing code
-and I liked the challenge of learning and mastering the C++ language. My
-first C++ book was "C++ Nuts & Bolts for Experienced Programmers", 1995, by
-Herbert Schildt, and I read that book cover-to-cover in about 2 days. Then I
-read Bjarne Stroustrup's book "The C++ Programming Language, 2nd Edition" a
-few months after that. While that book mostly just covered the C++ language,
-Stroustrup made some references to writing tests and some other basic software
-engineering best practices but it was very minimal (after all, this was a book
-about a programming language, not software engineering). Later my first year
-of graduate school I was introduced to the book "Design Patterns", 1994 by the
-Gang of Four, by a Computer Science Ph.D. student at CMU. Armed with the
-knowledge of C++ and Design Patterns, I set about writing a sizable amount of
-software implementing advanced numerical algorithms for constrained
-optimization as part of my Ph.D. work (the optimization package at that point
-was called rSQP++ for reduced successive quadratic programming).
+## Background
+
+To provide some context and motivation for this reading list, here I describe
+some of my background and experiences related to my software development
+journey. It is my hope that others can avoid the path that I took and instead
+educate themselves about software development sooner than I did.
+
+When I started my Ph.D. in Chemical Engineering in 1996 at Carnegie Mellon
+University (CMU), I knew that I liked writing code and I liked the challenge
+of learning and mastering the C++ language. My first C++ book was "C++ Nuts &
+Bolts for Experienced Programmers", 1995, by Herbert Schildt, and I read that
+book cover-to-cover in about 2 days. A few months after that I read Bjarne
+Stroustrup's book [*The C++ Programming Language, 2nd
+Edition*](#the_cxx_programming_language_special_edition). While that book
+mostly just covered the C++ language, Stroustrup made some references to
+writing tests and some other basic software engineering best practices but it
+was very minimal (after all, this was a book about a programming language, not
+software engineering). Later my first year of graduate school I was
+introduced to the book [*Design Patterns*](#design_patterns_1995) by a
+Computer Science Ph.D. student at CMU. Armed with the knowledge of C++ and
+Design Patterns, I set about writing a sizable amount of software implementing
+advanced numerical algorithms for constrained optimization as part of my
+Ph.D. work (the optimization package at that point was called rSQP++ for
+reduced successive quadratic programming).
When I started working at Sandia National Labs in 2001 after my Ph.D., I
continued writing object-oriented parallel numerical software in C++,
-extending my Ph.D. software package rSQP++ to support parallel computations
-with MPI (where the name was changed from rSQP++ to MOOCHO). Around 2003, I
-added the source code (and history) for MOOCHO to the Trilinos project version
-control repository. Once in Trilinos, I created or significantly contributed
-to many Trilinos packages. By 2007 I had written a lot of software and was a
-prolific contributor to Trilinos (the largest contributor to Trilinos in terms
-of number of commits and lines of source code). During that entire period
-from 1996 till 2007 I believed that I was writing quality object-oriented C++
+extending my Ph.D. software package [rSQP++](../publications#rsqpxx_2003) to
+support parallel computations with MPI (where the name was changed from rSQP++
+to [MOOCHO](../publications#moocho_2009)). Around 2003, I added the source
+code (and history) for MOOCHO to the Trilinos project version control
+repository. Once in Trilinos, I created or significantly contributed to many
+Trilinos packages. By 2007 I had written a lot of software and was a prolific
+contributor to Trilinos (the largest contributor to Trilinos in terms of
+number of commits and lines of source code). During that entire period from
+1996 till 2007 I believed that I was writing quality object-oriented C++
software. Then, in 2007, I began reading a larger portion of the modern
software engineering literature (some of which is highlighted in the lists
below) and came to realize my own knowledge gap in best practices for creating
@@ -69,18 +75,23 @@ It is my hope that this reading list we be useful and will help motivate
others to go on the same journey. Once you are armed with this knowege, there
is no going back!
-# A) General Software Engineering Books
-
-## A.1) Most Recommended Software Engineering Books
+## A) General Software Engineering Books
Here is a set of books that I have read about general software engineering
that is largely independent of programming language (but is biased toward
-object-oriented languages) that I highly recommend to anyone who is serious
-about software development. These books are listed in the approximate order of
-importance and the order that I would recommend people read them in depending
-on interest and focus.
+object-oriented languages) that would recommend to anyone who is serious about
+software development.
+
+### A.1) Most Recommended Software Engineering Books
+
+This section lists the books that I have read that I would mostly highly
+recommend to anyone who is serious about software development. These books are
+listed in the approximate order of importance and the order that I would
+recommend people read them in depending on interest and focus.
-### McConnell, Steve. Code Complete (Second Edition). Microsoft Press, 2004
+
+
+#### McConnell, Steve. *Code Complete (Second Edition)*. Microsoft Press, 2004
This is the single most useful book I have ever read about software
development. I wish I had read the first edition of this book back when I
@@ -98,11 +109,11 @@ clear, and robust code have gone way up. After reading this book, I now look
at the design, structuring, and layout of software with the same level of
standards that I apply to writing journal quality papers.
-Disclaimer: Steve's advice on C++ is not the most current. He appears to be a
+*Disclaimer:* Steve's advice on C++ is not the most current. He appears to be a
much more accomplished C programmer. For specific C++ advice, refer the
Effective C++ (3rd edition) and other C++ references given below.
-### Feathers, Michael. Working Effectively with Legacy Code. Prentice Hall, 2005
+#### Feathers, Michael. *Working Effectively with Legacy Code*. Prentice Hall, 2005
This is really the book that gives me hope that we can take very bad software
and through targeted incremental unit testing and refactoring, can turn it
@@ -124,7 +135,7 @@ convinced about unit testing. After reading this book, I unit test almost
every non-trivial code as a rule and it has massively improved the quality of
the software that I write. There is no going back for me.
-### Martin, Robert C. Agile Software Development (Principles, Patterns, and Practices). Prentice Hall, 2003
+#### Martin, Robert C. *Agile Software Development (Principles, Patterns, and Practices)*. Prentice Hall, 2003
After Code Complete (2nd Edition), this is the next book that I would most
highly recommend. While Code Complete (2nd edition) covers object-oriented
@@ -137,66 +148,72 @@ classes (i.e. packages). These eleven principles are:
General OO Principles:
-1) SRP (Single Responsibility Principle): Classes should have only one reason
-to change.
+* **1) SRP** (Single Responsibility Principle): Classes should have only one
+reason to change.
-2) OCP (Open-Closed Principle): Software entities (classes, modules,
+* **2) OCP** (Open-Closed Principle): Software entities (classes, modules,
functions, etc.) should be open for extension, but closed for modification.
-3) LSP (Liskov Substitution Principle): Subtypes must be substitutable for
-their base types.
+* **3) LSP** (Liskov Substitution Principle): Subtypes must be substitutable
+for their base types.
-4) DIP (Dependency Inversion Principle): Abstractions should not depend on
-details. Details should depend on abstractions.
+* **4) DIP** (Dependency Inversion Principle): Abstractions should not depend
+on details. Details should depend on abstractions.
-5) ISP (Interface Segregation Principle): Clients should not be forced to
-depend upon methods that they do not use. Interfaces belong to clients, not to
-hierarchies.
+* **5) ISP** (Interface Segregation Principle): Clients should not be forced
+to depend upon methods that they do not use. Interfaces belong to clients, not
+to hierarchies.
Package Cohesion OO Principles:
-6) REP (Release-Reuse Equivalency Principle): The granule of reuse is the
-granule of release.
+* **6) REP** (Release-Reuse Equivalency Principle): The granule of reuse is
+the granule of release.
-7) CCP (Common Closure Principle): The classes in a package should be closed
-together against the same kinds of changes. A change that affects a closed
-package affects all the classes in that package and no other packages.
+* **7) CCP** (Common Closure Principle): The classes in a package should be
+closed together against the same kinds of changes. A change that affects a
+closed package affects all the classes in that package and no other packages.
-8) CRP (Common Reuse Principle): The classes in a package are used
+* **8) CRP** (Common Reuse Principle): The classes in a package are used
together. If you reuse one of the classes in a package, you reuse them all.
Package Coupling OO Principles:
-9) ADP (Acyclic Dependencies Principle): Allow no cycles in the package dependency graph.
+* **9) ADP** (Acyclic Dependencies Principle): Allow no cycles in the package
+dependency graph.
-10) SDP (Stable Dependencies Principle): Depend in the direction of stability.
+* **10) SDP** (Stable Dependencies Principle): Depend in the direction of
+stability.
-11) SAP (Stable Abstractions Principle): A package should be as abstract as it
-is stable.
+* **11) SAP** (Stable Abstractions Principle): A package should be as abstract
+as it is stable.
These principles distill a great deal of object-orientation know-how down to
short acronyms like OCP (Open-Closed Principle). The other chapters that
describe many design patterns are also very useful like Chapters 13-17, 21,
23-29. Some of these design patterns are the same as given in the well known
-book Design Patterns (see below), while others are new (at least to me). Even
-with those patterns that are the same as in Design Patterns, Martin gives them
-more context and helps to really flesh them out. This is great stuff.
-
-Disclaimer: This book is poorly named. While the introductory chapters discuss
-Extreme Programming (XP), the remaining chapters of the book have little to do
-with XP specifically and are only mildly related to Agile methods in
-general. In fact, the discussion in Chapter 20 on packaging issues (while it
-contains great material) runs contrary to more modern Agile approaches that
-use continuous integration (see Continuous Integration below). Unless a reader
-is specifically interested in Agile methods, I would suggest that they just
-skim through Chapters 1-6. I suspect that the majority of this book was
-written well before the Agile angle was decided on and the title was mainly a
-sales ploy to take advantage of the hot new term "Agile". Also, this book has
-many examples; some are helpful but most (at least for me) were beating a dead
-horse (i.e. I already got the point). For other readers, the examples may be
-more helpful if they do not understand the points in the text.
-
-### Evans, Eric. Domain-Driven Design. Addison Wesley, 2004
+book [*Design Patterns*](#design_patterns_1995), while others are new (at
+least to me). Even with those patterns that are the same as in Design
+Patterns, Martin gives them more context and helps to really flesh them
+out. This is great stuff.
+
+*Disclaimer:* This book is poorly named. While the introductory chapters
+discuss Extreme Programming (XP), the remaining chapters of the book have
+little to do with XP specifically and are only mildly related to Agile methods
+in general. In fact, the discussion in Chapter 20 on packaging issues (while
+it contains great material) runs contrary to more modern Agile approaches that
+use continuous integration (see [*Continuous
+Integration*](#continuous_integration_2007)). Unless a reader is specifically
+interested in Agile methods, I would suggest that they just skim through
+Chapters 1-6. I suspect that the majority of this book was written well before
+the Agile angle was decided on and the title was mainly a sales ploy to take
+advantage of the hot new term "Agile". Also, this book has many examples; some
+are helpful but most (at least for me) were beating a dead horse (i.e. I
+already got the point). For other readers, the examples may be more helpful if
+they do not understand the points in the text.
+
+
+
+#### Evans, Eric. *Domain-Driven Design*. Addison Wesley, 2004
This is a more advanced book on software engineering analysis and design. The
main focus of the book is on how to develop a deep supple model for a domain
@@ -212,23 +229,23 @@ should be more practically useful to all software developers. Actually, I
think Chapter 10 is so good that it deserves to be read even if the rest of
the book is not.
-Disclaimer: This book has a large bias for IT-type domains and for programming
-languages like Java and Python where all memory is managed through implicit
-pointers/references. Specifically, the definition of VALUE OBJECTs needs to be
-refined for use in C++ that has true value objects. Also, SERVICES might just
-as well be non-member functions in C++ rather than to be shoe-horned into an
-object as a SERVICE. Anyway, the content in the book needs to be revised for
-C++. Note that Evans appears to feel that C++ is not a very good language for
-MODEL-DRIVEN DESIGN. One example reference is given in Domain-Driven Design
-Quickly (see below) where Evans states "Java has been the default choice of
-the last few years � It has garbage collection, which, in practice, turns out
-to be essential. (In contrast to C++, which just demanded too much attention
-to low-level details.)". Notice the past tense word "demanded"; it seems clear
-that Evans sees C++ as the past. I don't see this bias as a problem in
-adopting these ideas in a C++ environment but this bias is something to keep
-in mind when reading the book.
-
-### Poppendieck, Mary and Tom. Implementing Lean Software Development. Addison Wesley, 2007
+*Disclaimer:* This book has a large bias for IT-type domains and for
+programming languages like Java and Python where all memory is managed through
+implicit pointers/references. Specifically, the definition of VALUE OBJECTs
+needs to be refined for use in C++ that has true value objects. Also, SERVICES
+might just as well be non-member functions in C++ rather than to be
+shoe-horned into an object as a SERVICE. Anyway, the content in the book needs
+to be revised for C++. Note that Evans appears to feel that C++ is not a very
+good language for MODEL-DRIVEN DESIGN. One example reference is given in
+"Domain-Driven Design Quickly" where Evans states "Java has been the default
+choice of the last few years ... It has garbage collection, which, in
+practice, turns out to be essential. (In contrast to C++, which just demanded
+too much attention to low-level details.)". Notice the past tense word
+"demanded"; it seems clear that Evans sees C++ as the past. I don't see this
+bias as a problem in adopting these ideas in a C++ environment but this bias
+is something to keep in mind when reading the book.
+
+#### Poppendieck, Mary and Tom. *Implementing Lean Software Development*. Addison Wesley, 2007
This is a fantastic book about modern Agile software development. Here, the
authors cover several aspects of software development that I did not find in
@@ -254,19 +271,20 @@ chapter "Journey" gives a great condensed summary of the whole book. If you
read nothing else, read this last "Try this" section and go back in the book
to look for further details and explanations.
-Disclaimer: At the foundation for "Lean" software development is an analogy to
-the Toyota Production System (TPS) for manufacturing. As with any such analogy
-one can go too far (see "Code Complete: 2nd edition" for a discussion of this
-issue) but the authors appear to be able to only take the manufacturing
-analogy as far as it can be usefully applied and not any further.
+*Disclaimer:* At the foundation for "Lean" software development is an analogy
+to the Toyota Production System (TPS) for manufacturing. As with any such
+analogy one can go too far (see [*Code Complete (2nd
+edition)*](#code_complete_2nd_edition)) for a discussion of this issue) but
+the authors appear to be able to only take the manufacturing analogy as far as
+it can be usefully applied and not any further.
-## A.2) Recommended Software Engineering Books
+### A.2) Recommended Software Engineering Books
This next set of books provides valuable information on general software
engineering but I do not recommend them quite as highly as the books described
-above.
+above. However, many of these are still considered classics.
-### Fowler, Martin. UML Distilled (Third Edition). Addison Wesley, 2004
+#### Fowler, Martin. *UML Distilled (Third Edition)*. Addison Wesley, 2004
A picture is worth a thousand words and a single well-written UML class
diagram can be worth 10,000 lines of raw C++ code. This is the third edition
@@ -277,7 +295,9 @@ well with others. Fowler also sprinkles in several little tidbits of great
information like on "Design by Contract" about invariants, pre-conditions and
post-conditions. This is a great read.
-### Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns. Addison Wesley, 1995
+
+
+#### Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. *Design Patterns (Elements of Reusable Object-Oriented Software*. Addison Wesley, 1995
This is the seminal work that really launched the patterns movement in
software engineering. This was the book that I read where the "light went on"
@@ -289,14 +309,14 @@ FACADE, PROXY, ITERATOR, OBSERVER, and STRATEGY. If I had to pick my four
favorite design patterns, I would say they are ABSTRACT FACTORY, COMPOSITE,
DECORATOR, and STRATEGY.
-Disclaimer: Some of these design patterns in this book are more useful than
+*Disclaimer:* Some of these design patterns in this book are more useful than
others. First, I think the SINGLETON pattern has done great harm to the
software development community since it has been used as an excuse to abuse
global data (no way around it). Also, I have found little to no use for the
patterns FLYWEIGHT, CHAIN OF RESPONSIBILITY, no INTERPRETER (but perhaps I
will some day).
-### Beck, Kent. Test Driven Development. Addison Wesley, 2003
+#### Beck, Kent. *Test Driven Development*. Addison Wesley, 2003
I am not wildly excited about this book but it does sharply define Test Driven
Development (TDD) that has been shown to be so effective. This book describes
@@ -304,7 +324,7 @@ how you can use unit (and other) tests to drive your day-to-day coding work in
a way that makes you more productive in every way. For me, all of the really
useful information was in the Preface, and Part III (Chapters 25-32).
-Disclaimer: I don't like the way the dialog in this book is written. There are
+*Disclaimer:* I don't like the way the dialog in this book is written. There are
way too many examples that are used to demonstrate concepts that are
abundantly clear to me in the prose text. I get the feeling that Beck is
writing this book to the lowest common denominator of programmers. Therefore,
@@ -312,7 +332,7 @@ I got all that I needed out of Part III; I did not need the long-winded
examples in Parts I and II (but they might be more useful for some other
people).
-### Fowler, Martin. Refactoring (Improving the Design of Existing Code). Addison Wesley, 1999
+#### Fowler, Martin. *Refactoring (Improving the Design of Existing Code)*. Addison Wesley, 1999
Continuous refactoring is one of the most important practices in all Agile
programming methods, right up there with TDD. Without the ability to refactor,
@@ -321,7 +341,9 @@ than a straight Water Fall method. Most of the book is a catalog; you can read
the most important overview information in just a few Chapters (e.g., Preface,
Chapters 1-4 and 13-15).
-### Duvall, Paul, et al. Continuous Integration. Addison Wesley, 2007
+
+
+#### Duvall, Paul, et al. *Continuous Integration*. Addison Wesley, 2007
This is a recent book that covers many aspect of software management from
day-to-day development, to integration, to deployment, to post-delivery
@@ -331,7 +353,7 @@ without experiencing wasted time working with broken code. It also describes
how to make release and deployment "non-events". This book is very Agile
friendly.
-### Beck, Kent. Extreme Programming (Second Edition). Addison Wesley, 2005
+#### Beck, Kent. *Extreme Programming (Second Edition)*. Addison Wesley, 2005
Extreme Programming (XP) is called "extreme" for a reason. There are some
radical ideas that Beck lays out in this book. While the Values and Principles
@@ -339,10 +361,11 @@ of XP are undisputed in the Agile community, some of the actual Practices are
less widely used. The practices can be seen as worthy goals in many cases but
apparently there is no record of any successful software project that has used
all of the practices. For example, XP suggests no extra documentation at all
-beyond the code. The advice in "Domain Driven Design" is a little more
-reasonable and suggests a small amount of extra documentation beyond the code.
+beyond the code. The advice in [*Domain-Driven
+Design*](#domain_driven_design_2004) is a little more reasonable and suggests
+a small amount of extra documentation beyond the code.
-Disclaimer: Extreme Programming (XP) is called "extreme" for a reason. Some of
+*Disclaimer:* Extreme Programming (XP) is called "extreme" for a reason. Some of
the practices that Beck recommends are a bit "extreme" like requiring that
every line of production code be written in pairs doing pair
programming. There is a general softening of many of these practices as
@@ -351,7 +374,7 @@ http://blogs.construx.com/blogs/stevemcc/archive/2007/10/08/5-questions-on-agile
and www.construx.com (do a local search on "Legacy of Agile Software
Development" on that page).
-### Schwaber, Ken and Mike Beedle. Agile Software Development with Scrum. Prentice Hall, 2002
+#### Schwaber, Ken and Mike Beedle. *Agile Software Development with Scrum*. Prentice Hall, 2002
This is one of the first major books on the Scrum software development
process. Scrum is primarily about software project management dealing with how
@@ -368,24 +391,27 @@ development effort) and make them accountable for the outcome, then it is hard
to argue against Scrum. Even for big upfront design (BUFD) method, you should
consider using Scrum to drive the actual low-level development work.
-Disclaimer: Even through this book is as recent as 2002, it is a little out of
-date with respect to the current best practices in Agile software
+*Disclaimer:* Even through this book is as recent as 2002, it is a little out
+of date with respect to the current best practices in Agile software
development. One example of an out-dated principle is that idea that "quality"
should be one of the variables in a software project. When defined in a
certain way (e.g. how polished a user interface is) one can accept "quality"
as a variable but in general, fundamental internal software quality should
-never be negotiable (see Kniberg's book mentioned below). Also, some of the
-details of the Scrum process have been refined some in recent years (see Scrum
-and XP from the Trenches and Agile Project Management with Scrum).
+never be negotiable (see Kniberg's book [*Scrum and XP from the
+Trenches*](#scrum_and_xp_from_the_trenches_2007)). Also, some of the details
+of the Scrum process have been refined some in recent years (see [*Scrum and XP
+from the Trenches*](#scrum_and_xp_from_the_trenches_2007)).
+
+
-### Kniberg, Henrik. Scrum and XP from the Trenches. Info, 2007
+#### Kniberg, Henrik. *Scrum and XP from the Trenches*. Info, 2007
In this book, the author describes how they implemented Scrum in his software
organization and he goes into a lot of the practical details of working with
Scrum on a day-to-day basis. Also, this book gives some of the updated best
practices of Scrum that are more recent. Lots of good stuff here.
-### Brooks, Frederick. The Mythical Man Month: 20th Anniversary Edition. Addison Wesley, 1995
+#### Brooks, Frederick. *The Mythical Man Month: 20th Anniversary Edition*. Addison Wesley, 1995
Those ignorant of history are doomed to repeat the mistakes of the past. That
was my primary motivation for reading this book. This book is a well-known
@@ -395,9 +421,9 @@ published in 1975 and contains the experience and insight of the author
System 360 project from the mid-1960s! That means that in 2009 (when I first
read this book) that much of the knowledge and experience contained in this
book goes back almost 45 years! The first 15 chapters of this 20th anniversary
-edition are exactly the same as published in the original edition back in
-1975. There are four additional chapters with some updated information as of
-1995 (when the 20th anniversary edition was published). The added chapter 18
+edition are exactly the same as published in the original edition in 1975.
+There are four additional chapters with some updated information as of 1995
+(when the 20th anniversary edition was published). The added chapter 18
"Propositions of the Mythical Man Month: True of False?" is a great summary of
the (original) first 15 chapters. Going over these propositions, you see a
great many of the ideas and foundations for modern (2009) Lean/Agile software
@@ -414,7 +440,7 @@ that Lean/Agile methods are more consistent with the long standing wisdom in
the software engineering community than the process-heavy methods of the late
80s and 90s (i.e. CMM(I) and related methods).
-Disclaimer: While many of the observations and advice in this book are
+*Disclaimer:* While many of the observations and advice in this book are
consistent with modern Lean/Agile, a good bit of it is not and Dr. Brooks
acknowledges this in the later 1995 chapters. In particular, much of the 1975
material assumes a variation of the Water Fall method which he strongly
@@ -424,9 +450,15 @@ every part of the code which he totally changed his mind on in 1995 and has
come to believe in interfaces, specialization, and information hiding (see
Chapter 19).
-# B) C++ Books
+## B) C++ Books
+
+*Disclaimer:* This list of books was compiled in 2008 when C++98/03 was the
+current C++ standard. Much has changed with the introduction of the newer and
+improved C++11, C++14 and C++17 standards. However, much of the advice
+provided in these books still holds up in these more modern C++ standards.
+(And there are still billions of lines of C++ written in C++03.)
-## B.1) Most Recommended C++ Books
+### B.1) Most Recommended C++ Books
Here I list several books on C++ that I suspect will be the most useful for
beginning and experienced C++ developers. I list these books in the order of
@@ -439,55 +471,63 @@ given below were written before 1998 so be careful of some of the advice you
find in them. Refer to the newer books (such as Effective C++ (3rd edition)
and C++ Coding Standards) for more current advise.
-### Meyers, Scott. Effective C++ (Third Edition). Addison Wesley, 2005
+
-The book describes the most current, best advice on how to write good C++ code
-and stay out of trouble. This book is not the first book that a beginner would
-read on C++ but it is probably the second.
+#### Meyers, Scott. *Effective C++ (Third Edition)*. Addison Wesley, 2005
-### Sutter, Herb and Andrei Alexandrescu. C++ Coding Standards. Addison Wesley, 2005
+The book describes the most current, best advice on how to write good C++03
+code and stay out of trouble. This book is not the first book that a beginner
+would read on C++03 but it is probably the second.
+
+#### Sutter, Herb and Andrei Alexandrescu. *C++ Coding Standards*. Addison Wesley, 2005
Here is a catalog of 101 items that summarize most of the C++ communities'
-best practices. The authors are well respected in the C++ community and they
-provide many references to other respected authorities for every item. In my
-opinion, some of these principles are more important than others, but on the
-whole I highly recommend this book.
+best practices (in C++03). The authors are well respected in the C++ community
+and they provide many references to other respected authorities for every
+item. In my opinion, some of these principles are more important than others,
+but on the whole I highly recommend this book.
-Disclaimer: Some of the items are not appropriate for all situations or are
+*Disclaimer:* Some of the items are not appropriate for all situations or are
just not quite correct in my opinion. I amend and nullify some of the items in
the Appendix of the tech report "Thyra Coding and Documentation Guidelines"
-(see my publications list).
+(see [my publications list](../publications)).
+
+
-### Stroustrup, Bjarne. The C++ Programming Language (Special Edition). Addison Wesley, 2000
+#### Stroustrup, Bjarne. *The C++ Programming Language (Special Edition)*. Addison Wesley, 2000
Bjarne Stroustrup is the original implementer of C++ and is still highly
-involved in the C++ standardization process (see the paper Evolving a language
-in and for the real world: C++ 1991-2006 mentioned below). Most beginning C++
-programmers find this book hard to get through but it provides a very
+involved in the C++ standardization process (see [*Evolving a language in and
+for the real world: C++ 1991-2006*](#evolving_cxx_1991_2006)). Most beginning
+C++ programmers find this book hard to get through but it provides a very
comprehensive treatment of the C++ language and standard C++ library (i.e.,
-the ISO C++ 98 standard). In later chapters, Stroustrup also gives a lot of
+the ISO C++98 standard). In later chapters, Stroustrup also gives a lot of
good advice on object-oriented design that is very compatible with everything
-more recent that you will read coming out of the Agile community for instance.
+more recent that you will read coming out of the Agile community for
+instance. (Note that this is essentially the same book as "The C++ Programming
+Language (2nd Edition)", just with a hard cover.)
-Disclaimer: Some of the advice in this book goes contrary to more recent best
+*Disclaimer:* Some of the advice in this book goes contrary to more recent best
practices in the C++ community. For example, where TC++PL and C++ Coding
Standards differ, go with the guidance in the latter.
-### Meyers, Scott. More Effective C++. Addison Wesley, 1996
+#### Meyers, Scott. *More Effective C++*. Addison Wesley, 1996
-While Effective C++ (3rd Edition) provides basic information on C++, this book
-goes into some more advanced C++ concepts. This book describes a number of
-useful concepts and is a great place to look for ideas. For example, I put
-Item 28 on smart pointers and Item 29 on reference counting together and came
-up with the idea of smart reference-counted pointers that has evolved into the
-current Teuchos::RCP class (see my tech report on this in my publications
-list).
+While [*Effective C++ (3rd Edition)*](#effective_cxx_3rd_edition) provides
+basic information on C++98/03, this book goes into some more advanced C++
+concepts. This book describes a number of useful concepts and is a great place
+to look for ideas. For example, I put Item 28 on smart pointers and Item 29 on
+reference counting together and came up with the idea of smart
+reference-counted pointers that has evolved into the current Teuchos::RCP
+class (see paper [*Teuchos C++ Memory Management Classes, Idioms, and Related
+Topics: The Complete
+Reference*](../publications#teuchos_cxx_mem_mng_classes)).
-Disclaimer: This book was published in 1995 (i.e., before the ISO C++ 98
+*Disclaimer:* This book was published in 1995 (i.e., before the ISO C++ 98
standard) and some of the material is not relevant anymore. For example, much
of the material in Items 32, and 35 is obsolete.
-## B.2) Recommended Books on the Fine Details of C++
+### B.2) Recommended Books on the Fine Details of C++
If you really want to know the gory details of C++ and how to do crazy
powerful things with it, the following books will provide a lot of in-depth
@@ -495,49 +535,52 @@ information. I have not read every word in these books but I often refer to
them whenever I get stuck and can't understand why C++ is not compiling my
code or my program is not behaving the way that I expect.
-### Dewhurst, Stephen, C. C++ Gotchas. Addison Wesley, 2003
+#### Dewhurst, Stephen, C. *C++ Gotchas*. Addison Wesley, 2003
The author gives a list of 99 items that describe a lot of the ways to get
into trouble with C++ and how to avoid them. The fact that someone can
actually write an entire book on "C++ Gotchas" is just another indication of
how complex this language is and why very few people really excel in using it.
+(In some ways, it also exposes some of the languages most serious deficiencies
+that no upcoming C++ standard can fix, and still call it C++.)
-### Vandevoorde, David, and Nicolai M. Josuttis. C++ Templates. Addison Wesley, 2003
+#### Vandevoorde, David, and Nicolai M. Josuttis. *C++ Templates*. Addison Wesley, 2003
Here, the authors provide a very rigorous treatment of templates that would be
-recommended for anyone writing non-trivial templated code. This book contains
-material from the basic usage of templates to very advanced techniques. This
-book also describes the nitty-gritty details of overload resolution of C++
-functions including how templated functions fit in. This is very helpful when
-you are not sure why some code does not compile the way you think it should.
+recommended for anyone writing non-trivial C++03 templated code. This book
+contains material from the basic usage of templates to very advanced
+techniques. This book also describes the nitty-gritty details of overload
+resolution of C++ functions including how templated functions fit in. This is
+very helpful when you are not sure why some code does not compile the way you
+think it should.
-### Alexandrescu, Andrei. Modern C++ Design. Addison Wesley, 2001
+#### Alexandrescu, Andrei. *Modern C++ Design*. Addison Wesley, 2001
This book describes some very advanced template-programming techniques with
-C++. If you are writing any type of complex template code, I would highly
+C++03. If you are writing any type of complex template code, I would highly
recommend that you have this book and know what information it contains so
that you can find it when you need specific information.
-### Ellis, Margaret, and Bjarne Stroustrup. C++: The Annotated Reference Manual. Addison Wesley, 1990
+#### Ellis, Margaret, and Bjarne Stroustrup. *C++: The Annotated Reference Manual*. Addison Wesley, 1990
This is a very old book on C++, the oldest that I mention in this list of
references. This book was meant to provide the starting point for what would
-become the official 1998 C++ standard. What is useful about this book is that
-is provides very low-level details on the inner workings of C++ and gives lots
-of examples of how C++ compilers implement common language features. For
+become the first offical C++98 standard. What is useful about this book is
+that is provides very low-level details on the inner workings of C++ and gives
+lots of examples of how C++ compilers implement common language features. For
instance, if you want to know how virtual functions are commonly implemented
and why they are so efficient, there are good examples given.
-## B.3) Recommended Books on the History of C++ and why it has its current form
+### B.3) Recommended Books on the History of C++ and why it has its current form
When looking at its current form, it is clear that C++ is a language that was
grown (i.e. evolved) while it was being actively used to write millions of
lines of code over many years. No one would set out to design a language from
-scratch that looks like the current version of C++98. Therefore, if you really
-want to know why C++ is the way it is, the following publications from Bjarne
-Stroustrup are very illuminating.
+scratch that looks like C++98. Therefore, if you really want to know why C++
+is the way it is, the following publications from Bjarne Stroustrup are very
+illuminating.
-### Stroustrup, Bjarne. The Design and Evolution of C++. Addison Wesley, 1994
+#### Stroustrup, Bjarne. *The Design and Evolution of C++*. Addison Wesley, 1994
If want to know where C++ came from and why most of the language is the way it
is, this is the book to read. This book covers the inception, development, and
@@ -545,10 +588,9 @@ growth of C++ from pre-1980 to 1993. I think to be a truly great C++
programmer and understand how to use C++ effectively, you need to know much of
what is in this book.
-### Stroustrup, Bjarne. Evolving a language in and for the real world C++ 1991-2006
+
-HOPL III: Proceedings of the third ACM SIGPLAN conference on History of
-programming languages, AMC, New York, pages 4-1 to 4-59, 2007
+#### Stroustrup, Bjarne. *Evolving a language in and for the real world C++ 1991-2006*, HOPL III: Proceedings of the third ACM SIGPLAN conference on History of programming languages, AMC, New York, pages 4-1 to 4-59, 2007
In this proceedings paper, Stroustrup picks up where he left off in The Design
and Evolution of C++. This is especially a good read if you want some insight