You find the printing number as the first number on the last line of the copyright page.
I only list things that can affect understanding. Spelling mistakes you can fix yourself if you spot them. I very much appreciate reports of errors and constructive comments on the contents in general.
I will make this errata available via ftp somewhere in AW on ftp.std.com.
For brevity, I use the old replacement syntax: s/old/new/
- Bjarne
See sec17.5.2 for a way to explicitly request overloading of base and derived class functions.
This rule was the subject of much discussion and was eventually revised to match the rule for declarations in conditions (sec3.11.5.2). That is, a name introduced in a forstatement initializer goes out of scope at the end of the forstatement.
const true = 1; #define TRUE 1
Class templates as template arguments were approved at the March 1994 meeting in San Diego.
for(int i=0; i<str1.length() && i<str2.length(); i++)
if (!C::eq(str1[i],str2[i]))
return C::lt(str1[i],str2[i]);
return str2.length()-str1.length();
Member templates are described in sec15.9.3.
third line from bottom: s/I hope to see member templates in C++.//
void write(int vv) { v=vv; }
Naturally, I realized that not all constructors defined
meaningful and unsurprising implicit conversions. For example, a
vector type usually has a constructor taking an integer argument
indicating the number of elements. It was an unfortunate
sideeffect
to have v=7 construct a vector of seven elements and assign it to
v . I didn't consider this problem urgent, though. Several members
of the C++ standards committee (sec6.2), notably Nathan Myers,
suggested that a solution was necessary. In 1995, the problem was
solved by allowing the prefix explicit to be
added to the declaration
of a constructor. A constructor declared explicit is used for explicit
construction only and not for implicit conversions. For example,
declaring vector's constructor ``explicit vector(int);'' makes v=7
an error while the more explicit v=vector(7) as ever constructs and
assigns a vector .
In July 1994, the committee voted for ``CD registration'' as the first step of the completion of the ISO process is now called. Scheduling a standard isn't easy. In particular, ``details'' such as what a standard is and how you must make one aren't standardized and seem to change every year.
So how is the committee doing? We won't really know until the standard appears because there is no way of knowing how new proposals will fare. This summary is based on the state of affairs after the November 1994 meeting in Valley Forge.
Proposing extensions for C++ seems to be popular. For example:
There is some hope of restraint and that accepted features will be properly integrated into e language. Only a few new features have been accepted so far:
Exceptions and templates stand out among the extensions as being mandated by the original proposal and described in the ARM, and also by being a couple of orders of magnitudes more difficult to define and to implement than any of the other proposals.
To contrast, the committee has rejected many proposals. For example:
Please note that a rejection doesn't imply that the proposal was deemed bad or even useless. In fact, most proposals that reach the committee are technically sound and would help at least some subset of the C++ user community. The reason is that most ideas never make it through the initial scrutiny and effort to make it into a proposal.
Here, I have the great pleasure of eating my words! The committee did raise to the occasion and approved a splendid library of containers, iterators, and fundamental algorithms designed by Alex Stepanov. This library, often called the STL, is an elegant, efficient, formally sound, and welltested framework for containers and their use (Alexander Stepanov and Meng Lee: The Standard Template Library, HP Labs Technical Report HPL-94-34 (R. 1), August, 1994. Mike Vilot: An Introduction to the STL Library. The C++ Report, October 94). Naturally, the STL includes map and list classes, and subsumes the dynarray, bits, and bitstring classes mentioned above. In addition, the committee approved vector classes to support numeric/scientific computation based on a proposal from Ken Budge from Sandia Labs.
void h(RefNum r, Num& x)
{
r.bind(x); // error: no Num::bind
(&r)->bind(x); // ok: call RefNum::bind
}
s/this simple notion/this simple notion directly/
pd2 will point to the start of the D object passed, whereas
pd1 will point to the start of D 's B subobject.
const char cc = 'a';
const char* pcc = &cc;
const char** ppcc = &pcc;
void* pv = ppcc; // no cast needed:
// ppcc isn't a const, it only points to one,
// but const vanished!
char** ppc = (char**)pv; // points to pcc
void f()
{
**ppc = 'x'; // Zap!
}
In 1995, we found a scheme that allows some static checking of exception specifications and improved code generation without causing the problems described above. Consequently, exception specifications are now checked so that pointer to function assignments, initializations, and virtual function overriding cannot lead to violations. Some unexpected exceptions can still occur, and those are caught at run time as ever.
D&E was awarded one of ``Software Development'' Magazine's Productivity awards.
You can find reviews in
Thanks to Bjarne Stroustrup (bs@research.att.com) for the errata.
Markup, etc. by jutta@pobox.com, corrections and comments welcome.