more typo fixes

annotations/changelog

@@ -327,7 +327,7 @@ C++-annotations (9.7.0)
 
   * Rewrote all sections about multi-threading)
 
-  * Rewrote the section about lamba expressions
+  * Rewrote the section about lambda expressions
 
   * Replaced references to `ascii-z string' by `null terminated byte string'
     (NTBS), following the C++11 standard's terminology.
@@ -418,7 +418,7 @@ C++-annotations (9.2.1)
 
   * Removed excessive use of the verb 'will' from the Annotations. 
 
-  * The required operators for each of the standard interators (input,
+  * The required operators for each of the standard iterators (input,
     output, forward, bidirectional, random_access) are now explicitly
     mentioned in the paragraphs covering them.
 

annotations/yo/advancedtemplates/implementing.yo

@@ -53,7 +53,7 @@ tt(rhs). Its in-class implementation is
         )
 
     To retrieve the resulting tt(IntVect) a conversion operator is defined. We
-already encountered its implentation (in the previous section). Here is it,
+already encountered its implementation (in the previous section). Here is it,
 as an in-class implemented tt(BinExpr) member:
         verb(
     operator ObjType() const

annotations/yo/advancedtemplates/intro.yo

@@ -27,7 +27,7 @@ main characteristics of i(template meta programming) are introduced.
 In addition to template type and template non-type parameters there is a third
 kind of template parameter, the
     emi(template template parameter). This kind of template parameter is
-introduced shortly, laying the groundwork for the discusion of em(trait
+introduced shortly, laying the groundwork for the discussion of em(trait
 classes) and em(policy classes).
 
 This chapter ends with the discussion of several additional and interesting

annotations/yo/classes/subtleties.yo

@@ -102,7 +102,7 @@ these parentheses for us:
     itemization(
     it() Anonymous objects are great for initializing tt(const) reference
 parameters.
-    it() The same syntaxis, however, can also be used in stand-alone
+    it() The same syntax, however, can also be used in stand-alone
 statements, in which they are interpreted as variable definitions if our
 intention actually was to initialize an anonymous object using an existing
 object.

annotations/yo/classtemplates/cirquemembers.yo

@@ -16,7 +16,7 @@ tt(CirQue) declares several constructors and (public) members (their
 definitions are provided as well; all definitions are provided below the class
 interface).
 
-Here are the constructors and the destrctor:
+Here are the constructors and the destructor:
 
     itemization(
     ittq(explicit CirQue(size_t maxSize = 0))(Constructor initializing a

annotations/yo/classtemplates/converting.yo

@@ -176,7 +176,7 @@ multiple levels of inheritance let's summarize the steps that took to
 implement static polymorphism
     itemization(
     it() First, starting at the base class,
-the class tt(Vehicle). tt(Vehicle's) non-redifinable interface is moved
+the class tt(Vehicle). tt(Vehicle's) non-redefinable interface is moved
 to a class tt(VehicleBase), and tt(Vehicle) itself is turned into a statically
 polymorphic base class. In general all members of the original 
 polymorphic base class that do not use or implement virtual members should be
@@ -244,7 +244,7 @@ type. The following tt(main) function displays, respectively, 1000 and 15000:
     Note that this program implements tt(fun) twice, rather than once in the
 case of dynamic polymorphism. The same holds true for the tt(Vehicle) class
 template: two implementations, one for the tt(Car) type, and one for the
-tt(Truck) type. The statically polumorphic program will be slightly faster,
+tt(Truck) type. The statically polymorphic program will be slightly faster,
 though.
 
     (A compilable example using static polymorphism is found in the

annotations/yo/classtemplates/examplestaticpoly.yo

@@ -160,7 +160,7 @@ statically polymorphic base classes. If the base class defines data members
 and member functions, and if these additional members are used by derived
 class types, then each member has its own instantiation for each derived class
 type. This also results in i(code bloat), albeit of a different kind than
-obeserved with dynamic polymorphism. This kind of code bloat can often be
+observed with dynamic polymorphism. This kind of code bloat can often be
 somewhat reduced by deriving the base class from its own (ordinary,
 non-template) base class, encapsulating all elements of the statically
 polymorphic base class that do not depend on its template type parameters.

annotations/yo/classtemplates/externtemplate.yo

@@ -37,7 +37,7 @@ name a few): all are assumed by the compiler to have been instantiated
 elsewhere;
     it() Although the above source file em(compiles), the em(instantiations)
 of the templates must be available before the linker can build the final
-program. To accomplish this one or more sourcefiles may be constructed in
+program. To accomplish this one or more source files may be constructed in
 which all required instantiations are made available.
 
     In a stand-alone program one might postpone defining the required members

annotations/yo/classtemplates/fold.yo

@@ -9,7 +9,7 @@ Sometimes the arguments must be combined using binary operators (like tt(arg1
 + arg2 + ...)). In those cases a emi(folding expression) can be used instead
 of combining the arguments using a traditional variadic template.
 
-All binary operators (including the assignment, compount assignment and comma
+All binary operators (including the assignment, compound assignment and comma
 operators) can be used in folding expressions. 
 
     itemization(

annotations/yo/classtemplates/lambda.yo

@@ -1,4 +1,4 @@
-em(Generic lambda expressions) hi(lamda: generic) use tt(auto) to define their
+em(Generic lambda expressions) hi(lambda: generic) use tt(auto) to define their
 parameters. When used, an appropriate lambda expression is created by looking
 at the actual types of arguments. Since they are generic, they can be used
 inside one function with different types of arguments. Here is an example
@@ -62,7 +62,7 @@ its values via a lambda function:
 
 In generic lambda expressions the keyword tt(auto) indicates that the compiler
 determines which types to use when the lambda function is instantiated. A
-generic lamda expression therefore em(is) a class template, even though it
+generic lambda expression therefore em(is) a class template, even though it
 doesn't look like one. As an example, the following lambda expression defines
 a generic class template, which can be used as shown:
         verb(

annotations/yo/classtemplates/static.yo

@@ -35,7 +35,7 @@ looks like this:
     Here tt(s_objectCounter) is an tt(int) and is thus independent of the
 template type parameter tt(Type). Multiple instantiations of
 tt(s_objectCounter) for identical tt(Type)s cause no problem, as the linker
-will remove all but one instantation from the final executable (cf. section
+will remove all but one instantiation from the final executable (cf. section
 ref(TEMPFUNDECL)).
 
     In list-like constructions, where a i(pointer to objects) of the class

annotations/yo/classtemplates/variadicnontype.yo

@@ -1,4 +1,4 @@
-Variadic templates not necesssarily define template types. Non-types can also
+Variadic templates not necessarily define template types. Non-types can also
 be used with
     hi(variadic non-type parameters)
         variadic templates. The following function template accepts any series

annotations/yo/concrete/codegeneration.yo

@@ -1,5 +1,5 @@
 The calculator is built using tt(bisonc++) and tt(flexc++).  Here is the
-implentation of the calculator's tt(main) function:
+implementation of the calculator's tt(main) function:
         verbinclude(-a bisonc++/calculator.cc)
 
 The parser's files tt(parse.cc) and tt(parserbase.h) are generated by the

annotations/yo/concrete/fistreamexample.yo

@@ -22,7 +22,7 @@ tt(field) object, initialized in one of three different ways:
     itemization(
     itt(field()): When tt(setField)'s argument is a tt(field) object
         constructed by its default constructor the next extraction will use
-        the same fieldwidth as the previous extraction.
+        the same field width as the previous extraction.
     itt(field(0)): When this tt(field) object is used as tt(setField)'s
         argument, fixed-sized field extraction stops, and the tt(Fistream)
         acts like any standard tt(istream) object again.

annotations/yo/concrete/iterators.yo

@@ -1,5 +1,5 @@
 In section ref(RANDOMIT) the construction of iterators and
-reverse iteraters was discussed. In that section the iterator was constructed
+reverse iterators was discussed. In that section the iterator was constructed
 as an inner class in a class derived from a vector of pointers to strings.
 
     An object of this nested iterator class handles the dereferencing of the

annotations/yo/concrete/promotions.yo

@@ -4,7 +4,7 @@ promotions. E.g., a statement like
   result = rhs + 2;
         )
     generates a compilation error as promotions are not recognized by
-the template argument deduction algoritm. Currently, the above statement needs
+the template argument deduction algorithm. Currently, the above statement needs
 to be rewritten to have it accepted by the compiler:
         verb(
   result = rhs + Class{ 2 };

annotations/yo/containers/container.yo

@@ -60,7 +60,7 @@ A variant of the tt(pair) is the tt(complex) container, implementing
 operations that are defined on complex numbers.
 
 A tt(tuple) (cf. section ref(TUPLES)) generalizes the tt(pair) container to a
-data structure accomodating any number of different data types.
+data structure accommodating any number of different data types.
 
 All abstract containers described in this chapter as well as the tt(string)
 and stream datatypes (cf. chapters ref(String) and ref(IOStreams)) are part of

annotations/yo/containers/multimap.yo

@@ -61,5 +61,5 @@ non-existing keys: they both return the first element having a key that
 exceeds the provided key.
     it() Although the keys are ordered in the tt(multimap), the values for
 equal keys are not ordered: they are retrieved in the order in which they were
-enterd.
+entered.
     )

annotations/yo/friends/friendfun.yo

@@ -44,7 +44,7 @@ friend.
 hi(friend: function declaration) em(friend declarations) are not em(member)
 functions, and so they are independent of the class's tt(private, protected)
 and tt(public) sections. Friend declaration may be placed anywhere in the
-class interface. Convention dictates that friend declaractions are listed
+class interface. Convention dictates that friend declarations are listed
 directly at the top of the class interface. The class tt(Person), using
 tt(friend) declaration for its extraction and insertion operators starts like
 this:

annotations/yo/functiontemplates/insertion.yo

@@ -6,7 +6,7 @@ A conversion operator is guaranteed to be used as an rvalue. This means that
 objects of a class defining a tt(string) conversion operator can be assigned
 to, e.g., tt(string) objects. But when trying to insert objects defining
 tt(string) conversion operators into streams then the compiler complains that
-we're attemping to insert an inappropriate type into an tt(ostream).
+we're attempting to insert an inappropriate type into an tt(ostream).
 
 On the other hand, when this class defines an tt(int) conversion operator
 insertion is performed flawlessly.

annotations/yo/functiontemplates/limits.yo

@@ -100,7 +100,7 @@ can be used as follows:
         `Not-a-Number' value.
     )
     ithtq(infinity)(Type constexpr infinity())(
-        if available for tt(Type): its positive infiniy value.
+        if available for tt(Type): its positive infinity value.
     )
     ithtq(is_bounded)(bool is_bounded)(
         tt(true) if tt(Type) contains a finite set of values.

annotations/yo/functiontemplates/selection.yo

@@ -63,7 +63,7 @@ arguments.
 This implies that at least the number of arguments must match the number of
 parameters of the viable functions. Function 10's first argument is a
 tt(string). As a tt(string) cannot be initialized by an tt(int) value no
-approprate conversion exists and function 10 is removed from the list of
+appropriate conversion exists and function 10 is removed from the list of
 candidate functions.  tt(double) parameters can be retained. Standard
 conversions em(do) exists for tt(int)s to tt(double)s, so all functions having
 ordinary tt(double) parameters can be retained. Therefore, the set of viable

annotations/yo/functiontemplates/specialization.yo

@@ -17,7 +17,7 @@ a more specialized function over a less specialized one. So the template
 explicit specialization is selected whenever possible.
 
 A template explicit specialization offers a specialization for its template
-type parameter(s). The special type is consistently subsituted for
+type parameter(s). The special type is consistently substituted for
 the template type parameter in the function template's code. For
 example if the explicitly specialized type is tt(char const *) then in the
 template definition
@@ -86,7 +86,7 @@ case only a tt(Type const *), allowing tt(char const *)'s to be passed as
 arguments. There's no opportunity for a qualification transformation here.
 The qualification transformation allows the compiler to add a tt(const) to a
 non-const argument if the parameter itself (and em(not)  tt(Type)) is
-specified in terms of a tt(const) or tt(const &). Loooking at, e.g., tt(t1) we
+specified in terms of a tt(const) or tt(const &). Looking at, e.g., tt(t1) we
 see that it's defined as a tt(Type const *). There's nothing tt(const) here
 that's referring to the parameter (in which case it would have been tt(Type
 const *const t1) or tt(Type const *const &t1)). Consequently a qualification

annotations/yo/generic/foreach.yo

@@ -19,7 +19,7 @@ the tt(for_each) call, which argument is eventually also passed to the
 function given to tt(for_each). Within tt(for_each) the return value of the
 function that is passed to it is ignored. The tt(for_each) generic algorithm
 looks a lot like the range-based for loop, but different from the range-based
-for-loop the tt(for_each) algoritm can also be used with sub-ranges and with
+for-loop the tt(for_each) algorithm can also be used with sub-ranges and with
 reverse-iterators.
         )
         it() Example:

annotations/yo/generic/intro.yo

@@ -23,7 +23,7 @@ something akin to
     sort(first-element, last-element)
         )
 
-Generic algoritms should be used wherever possible. Avoid the urge to design
+Generic algorithms should be used wherever possible. Avoid the urge to design
 your own code for commonly encountered algorithms. Make it a habit to
 em(first) thoroughly search the generic algorithms for an available
 candidate. The generic algorithms should become your em(weapon of choice) when
@@ -43,7 +43,7 @@ i(generic data type). Furthermore, the particular type of iterator (see
 section ref(ITERATORS)) that is required is mentioned as well as other generic
 types that might be required (e.g., performing tt(BinaryOperations), like
 tt(plus<Type>)). Although iterators are commonly provided by abstract
-containers and comparable pre-defined data structrues, at some point you may
+containers and comparable pre-defined data structures, at some point you may
 want to design your own iterators. Section ref(ITERATORCONS) offers guidelines
 for constructing your own iterator classes and provides an overview of of
 operators that must be implemented for the various types of iterators.

annotations/yo/generic/transform.yo

@@ -36,7 +36,7 @@ function object's tt(operator()).
     )
     Also note that the range-based for loop can often be used instead of the
 tt(transform) generic algorithm. However, but different from the
-range-based for-loop the tt(transform) algoritm can also be used width
+range-based for-loop the tt(transform) algorithm can also be used width
 sub-ranges and with reverse-iterators.
 
 

annotations/yo/inheritance/move.yo

@@ -8,7 +8,7 @@ A derived class may offer a move constructor for two reasons:
 
     The design of move constructors moving data members was covered in section
 ref(MOVE). A move constructor for a derived class whose base class is
-move-aware must em(anonimize) the rvalue reference before passing it to the
+move-aware must em(anonymize) the rvalue reference before passing it to the
 base class move constructor. The tt(std::move) function should be used when
 implementing the move constructor to move the information in base classes or
 composed objects to their new destination object.
@@ -21,7 +21,7 @@ movable data members, but that its tt(Vehicle) base class is move-aware:
         verb(
     Car::Car(Car &&tmp)
     :
-        Land(std::move(tmp)),           // anonimize `tmp'
+        Land(std::move(tmp)),           // anonymize `tmp'
         d_brandName(tmp.d_brandName)    // move the char *'s value
     {
         tmp.d_brandName = 0;

annotations/yo/inheritance/related.yo

@@ -23,7 +23,7 @@ store and retrieve a vehicle's mass:
 corresponding object has been created. At a later stage the mass can be
 changed or retrieved.
 
-To represent vehicles travelling over land, a new class tt(Land) can be
+To represent vehicles traveling over land, a new class tt(Land) can be
 defined offering tt(Vehicle)'s functionality and adding its own specific
 functionality. Assume we are interested in the speed of land vehicles em(and)
 in their mass. The relationship between tt(Vehicle)s and tt(Land)s could of

annotations/yo/iostreams/iosbase.yo

@@ -17,7 +17,7 @@ class: the class ti(streambuf) or its derivatives.
 It is neither possible nor required to construct an tt(ios_base) object
 directly. Its construction is always a side-effect of constructing an object
 further down the class hierarchy, like tt(std::ios). tt(Ios) is the next
-class down the iostream hierarchy (see figure ref(IOCLASSESFIG)). Since all
+class down the iostream hierarchy (see Figure ref(IOCLASSESFIG)). Since all
 stream classes in turn inherit from tt(ios), and thus also from tt(ios_base),
 the distinction between tt(ios_base) and ti(ios) is in practice not
 important. Therefore, facilities actually provided by tt(ios_base) will be

annotations/yo/nested/nestedfriends.yo

@@ -9,7 +9,7 @@ are members of the outer class and thus can access all the outer class's
 members. Here is an example showing this principle. The example won't compile
 as members of the class tt(Extern) are denied access to tt(Outer)'s private
 members, but tt(Outer::Inner)'s members em(can) access tt(Outer)'s private
-memebrs:
+members:
         verb(
     class Outer
     {

annotations/yo/overloading/lambda.yo

@@ -20,7 +20,7 @@ that is irrelevant at the current level of specification. Nested classes don't
 solve these problems either. Moreover, nested classes can't be used in
 templates.
 
-Lamba expressions solve these problems.  A i(lambda expression) defines an
+lambda expressions solve these problems.  A i(lambda expression) defines an
     i(anonymous function object) which may immediately be passed to functions
 expecting function object arguments, as explained in the next few sections.
 

annotations/yo/overloading/lambdasyntax.yo

@@ -6,7 +6,7 @@ its emi(closure type).
 
 Lambda expressions are used inside blocks, classes or namespaces (i.e.,
 pretty much anywhere you like). Their implied closure type is defined in the
-smallest block, class or namespace scope containing the lamba
+smallest block, class or namespace scope containing the lambda
 expression. The closure object's visibility starts at its point of definition
 and ends where its closure type ends.
 
@@ -24,16 +24,16 @@ operator. Here is an example of a lambda expression:
     The function call operator of the closure object created by this lambda
 expression expects two tt(int) arguments and returns their product. It is an
 inline tt(const) member of the closure type. To drop the tt(const) attribute,
-the lamba expression should specify hi(lambda: mutable) tt(mutable), as
+the lambda expression should specify hi(lambda: mutable) tt(mutable), as
 follows:
         verb(
     [](int x, int y) mutable
     ...
         )
     The lambda-declarator may be omitted, if no parameters are defined, but
 when specifying tt(mutable) (or tt(constexpr), see below) the
-lambda-declarator must at least start with an empty set of parenthese. The
-parameters in a lamba declarator cannot be given default arguments. 
+lambda-declarator must at least start with an empty set of parentheses. The
+parameters in a lambda declarator cannot be given default arguments.
 
 Declarator specifiers can be tt(mutable), tt(constexpr), or both. A
 tt(constexpr) lambda-expression is itself a tt(constexpr), which may be
@@ -62,7 +62,7 @@ identical:
         )
 
 
-A closure object as defined by the previous lamda expression could be used e.g.,
+A closure object as defined by the previous lambda expression could be used e.g.,
 in combination with the tt(accumulate) (cf. section ref(ACCU)) generic
 algorithm to compute the product of a series of tt(int) values stored in a
 vector: