diff --git a/doc/modules/ROOT/pages/custom_rtti.adoc b/doc/modules/ROOT/pages/custom_rtti.adoc index 86103125..40a2e41c 100644 --- a/doc/modules/ROOT/pages/custom_rtti.adoc +++ b/doc/modules/ROOT/pages/custom_rtti.adoc @@ -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. diff --git a/doc/modules/ROOT/pages/headers.adoc b/doc/modules/ROOT/pages/headers.adoc index 8dd0eddf..0ecc3078 100644 --- a/doc/modules/ROOT/pages/headers.adoc +++ b/doc/modules/ROOT/pages/headers.adoc @@ -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++] diff --git a/doc/modules/ROOT/pages/multiple_dispatch.adoc b/doc/modules/ROOT/pages/multiple_dispatch.adoc index 6ea01342..9a696ddc 100644 --- a/doc/modules/ROOT/pages/multiple_dispatch.adoc +++ b/doc/modules/ROOT/pages/multiple_dispatch.adoc @@ -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 diff --git a/doc/modules/ROOT/pages/namespaces.adoc b/doc/modules/ROOT/pages/namespaces.adoc index 77b50d6b..28a15cb1 100644 --- a/doc/modules/ROOT/pages/namespaces.adoc +++ b/doc/modules/ROOT/pages/namespaces.adoc @@ -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. diff --git a/doc/modules/ROOT/pages/ref_macros.adoc b/doc/modules/ROOT/pages/ref_macros.adoc index c0c75ac9..1fc54a72 100644 --- a/doc/modules/ROOT/pages/ref_macros.adoc +++ b/doc/modules/ROOT/pages/ref_macros.adoc @@ -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] diff --git a/doc/modules/ROOT/pages/registries_and_policies.adoc b/doc/modules/ROOT/pages/registries_and_policies.adoc index bf611d2b..b83f4fe1 100644 --- a/doc/modules/ROOT/pages/registries_and_policies.adoc +++ b/doc/modules/ROOT/pages/registries_and_policies.adoc @@ -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 ``. 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`: diff --git a/doc/modules/ROOT/pages/virtual_ptr_alt.adoc b/doc/modules/ROOT/pages/virtual_ptr_alt.adoc index 44ce930d..2c936031 100644 --- a/doc/modules/ROOT/pages/virtual_ptr_alt.adoc +++ b/doc/modules/ROOT/pages/virtual_ptr_alt.adoc @@ -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