Ticket #9136: bimap-typo.patch

libs/bimap/doc/rationale.qbk

@@ -80 +80 @@
 Although this seems straightforward, as will be seen later, it is the
 most difficult code hack of the library. It is indeed very easy if we
 relax some of the efficiency constraints. For example, it is trivial if
-we allow a relation to have greater size than the the sum of those of
+we allow a relation to have greater size than the sum of those of
 its components. It is equally simple if access speed is not important.
 One of the first decisions made about [*Boost.Bimap] was, however, that, in
 order to be useful, it had to achieve zero overhead over the wrapped

libs/bimap/doc/tutorial.qbk

@@ -27 +27 @@
 bidirectional map. It is possible to control the collection type of each side
 of the relationship that the bimap represents, giving one-to-many
 containers, hashed bidirectional containers and others that may be more
-suitable to the the task at hand. The second section
+suitable to the task at hand. The second section
 ([link boost_bimap.the_tutorial.controlling_collection_types Controlling collection types])
 explains how to instantiate a bimap with different collection constraints.
 
@@ -85 +85 @@
 
 __STANDARD_MAPPING_FRAMEWORK__
 
-The left collection type depends on the selected map type. For example if the the map type is `std::multimap` the collection type of X is a `multiset_of`.
+The left collection type depends on the selected map type. For example if the map type is `std::multimap` the collection type of X is a `multiset_of`.
 The following table shows the equivalent types for the std associative containers.
 
 [table std associative containers

libs/bimap/example/tagged_simple_bimap.cpp

@@ -65 +65 @@
     }
 
     std::cout << std::endl
-              << "Countries names ordered alfabetically along with"
+              << "Countries names ordered alphabetically along with"
                  "their final position:"
               << std::endl;