forked from boostorg/mp11
Fix typo
This commit is contained in:
@@ -133,7 +133,7 @@ To do that, we need to first convert `std::tuple<int, float, void*>` to
|
||||
`mp_list<int, float, void*>`, apply `add_pointer` to each element obtaining
|
||||
`mp_list<int*, float*, void$$**$$>`, then convert that back to `std::tuple`.
|
||||
|
||||
These conversion steps are a quite common occurence, and we'll write a
|
||||
These conversion steps are a quite common occurrence, and we'll write a
|
||||
primitive that helps us perform them, called `mp_rename`. We want
|
||||
```
|
||||
mp_rename<std::tuple<int, float, void*>, mp_list>
|
||||
@@ -1097,7 +1097,7 @@ template<class T, class U> using sizeof_less = mp_bool<(sizeof(T) < sizeof(U))>;
|
||||
|
||||
Finally, let me show the implementations of `mp_count` and `mp_count_if`, for
|
||||
no reason other than I find them interesting. `mp_count<L, V>` returns the
|
||||
number of occurences of the type `V` in the list `L`; `mp_count_if<L, P>`
|
||||
number of occurrences of the type `V` in the list `L`; `mp_count_if<L, P>`
|
||||
counts the number of types in `L` for which `P<T>` is `true`.
|
||||
|
||||
As a first step, I'll implement `mp_plus`. `mp_plus` is a variadic (not just
|
||||
@@ -1175,7 +1175,7 @@ whether the list `L` contains the type `V`:
|
||||
template<class L, class V> using mp_contains = mp_bool<mp_count<L, V>::value != 0>;
|
||||
```
|
||||
At first sight, this implementation appears horribly naive and inefficient --
|
||||
why would we need to count all the occurences just to throw that away if we're
|
||||
why would we need to count all the occurrences just to throw that away if we're
|
||||
only interested in a boolean result -- but it's actually pretty competitive and
|
||||
perfectly usable. We just need to add one slight optimization to `mp_plus`, the
|
||||
engine behind `mp_count` and `mp_contains`:
|
||||
|
||||
@@ -681,7 +681,7 @@ as the first argument are:
|
||||
|
||||
|g$$++$$ 4.9.2, recursive |0.9 |4.7 |14.2 |32.4 |DNF |||
|
||||
|===
|
||||
To improve upon this apalling result, we'll again exploit pack expansion into a
|
||||
To improve upon this appalling result, we'll again exploit pack expansion into a
|
||||
function call, but in a novel way. Let's suppose that we need to access the
|
||||
fourth element (`I = 3`). We'll generate the function signature
|
||||
```
|
||||
@@ -838,7 +838,7 @@ one. We can pretty much tell who's going to win, and by how much.
|
||||
|
||||
The final algorithm that I'll bring to your attention is `mp_find_index`.
|
||||
`mp_find_index<L, V>` returns an integral constant of type `size_t` with a
|
||||
value that is the index of the first occurence of `V` in `L`. If `V` is not in
|
||||
value that is the index of the first occurrence of `V` in `L`. If `V` is not in
|
||||
`L`, the return value is the size of `L`.
|
||||
|
||||
We'll start with the recursive implementation, as usual:
|
||||
@@ -974,7 +974,7 @@ needs to manipulate type lists of length 300.
|
||||
|
||||
Note that once we have `mp_drop` and `mp_find_index`, we can derive the
|
||||
`mp_find<L, V>` algorithm, which returns the suffix of `L` starting with the
|
||||
first occurence of `V`, if any, and an empty list otherwise, by using
|
||||
first occurrence of `V`, if any, and an empty list otherwise, by using
|
||||
`mp_drop<L, mp_find_index<L, V>>`.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Reference in New Issue
Block a user