boostorg · jll63 · Feb 7, 2026 · Feb 7, 2026 · Feb 7, 2026 · Feb 7, 2026
@@ -152,7 +152,7 @@ include::{example}/2/custom_rtti.cpp[tag=type_ids]
 ----
 
 This is a problem, because `static_type` is called by
-`BOOST_OPENMETHOD_CLASSES`, also during static construction. There no guarantee
+`BOOST_OPENMETHOD_CLASSES`, also during static construction. There is no guarantee
 regarding the order of execution of static constructors across several
 translation units. `BOOST_OPENMETHOD_CLASSES` risks reading the type ids
 _before_ they have been assigned.

@@ -66,7 +66,7 @@ specialized for each overrider signature. Macro
 xref:BOOST_OPENMETHOD_OVERRIDER.adoc[BOOST_OPENMETHOD_OVERRIDER] takes the same
 arguments `BOOST_OPENMETHOD_OVERRIDE`, and expands to the corresponding
 specialization of the overrider container. Containers have a static member
-function `fn` that contains the body the overrider, provided by the user. We can
+function `fn` that contains the body of the overrider, provided by the user. We can
 call the overrider for `Employee` like so:
 
 [source,c++]

@@ -50,7 +50,7 @@ example - matrix addition:
 include::{example}/ambiguities/1/main.cpp[tag=content]
 ----
 
-The programs terminates with the following error message:
+The program terminates with the following error message:
 
 ```
 ambiguous

@@ -10,7 +10,7 @@ namespace. xref:BOOST_OPENMETHOD_OVERRIDE.adoc[BOOST_OPENMETHOD_OVERRIDE] works
 _across_ namespaces. Overriders are not required to be in the same namespace as
 the method they override. The macro adds the overrider to a method that can be
 called with the same arguments as the overrider, possibly located via argument
-dependant lookup.
+dependent lookup.
 
 Overrider containers are added to the current namespace. It follows that the
 same method can have overriders in multiple containers, in different namespaces.

@@ -1,7 +1,7 @@
 [#ref_macros]
 = xref:ref_macros.adoc[Macros]
 
-The following macros - in particular the first three- are sufficient for most
+The following macros - in particular the first three - are sufficient for most
 uses of the library.
 
 [cols=2]

@@ -9,7 +9,7 @@ Class templates cpp:use_classes[], cpp:method[], cpp:virtual_ptr[], and macros
 xref:BOOST_OPENMETHOD.adoc[BOOST_OPENMETHOD] and
 xref:BOOST_OPENMETHOD_CLASSES.adoc[BOOST_OPENMETHOD_CLASSES], take an additional
 argument, a cpp:registry[] class, which defaults to cpp:default_registry[]. The
-default registry can be overriden by defining the macroprocessor symbol
+default registry can be overridden by defining the macroprocessor symbol
 xref:BOOST_OPENMETHOD_DEFAULT_REGISTRY.adoc[BOOST_OPENMETHOD_DEFAULT_REGISTRY]
 _before_ including `<boost/openmethod/core.hpp>`. The value of the symbol is
 used as a default template parameter for `use_classes`, `method`, `virtual_ptr`,
@@ -87,7 +87,7 @@ When defining a new registry, it is recommended to define a new class, derived
 from `registry<...>`, rather than via a typedef, which would create excessively
 long symbol names and make debugging harder.
 
-A registry can calso be created by copying an existing registry's policies,
+A registry can also be created by copying an existing registry's policies,
 using the cpp:with[] and cpp:without[] nested templates. For example,
 `indirect_registry` is a tweak of `default_registry`:
 

@@ -5,7 +5,7 @@
 
 Virtual arguments can also be passed as plain references, plain pointers, or
 smart pointers, i.e. without using `virtual_ptr`. In a method declaration,
-parameters with a type wrappted in class template `virtual_` are considered in
+parameters with a type wrapped in class template `virtual_` are considered in
 overrider selection (along with `virtual_ptr` parameters).
 
 For example, the `Node` example can be rewritten as follows:
@@ -31,7 +31,7 @@ inline auto postfix(const Node& node, std::ostream& os) -> void {
 
 By itself, `virtual_` does not provide any benefits. Passing the virtual
 argument by reference almost compiles to the same code as creating a
-`virtual_ptr`, using it for one call, then throwing it way. The only difference
+`virtual_ptr`, using it for one call, then throwing it away. The only difference
 is that the virtual argument is passed as one pointer instead of two.
 
 However, we can now customize how the vptr is obtained. When the method sees a