doc: fix typos (#934)
This commit is contained in:
@@ -80,7 +80,7 @@ codebase has grown as more and more classes and functionalities were added.<br/>
|
||||
Here is a brief, yet incomplete list of what it offers today:
|
||||
|
||||
* Built-in **RTTI system** mostly similar to the standard one.
|
||||
* A `constexpr` utility for human readable **resource names**.
|
||||
* A `constexpr` utility for human-readable **resource names**.
|
||||
* Minimal **configuration system** built using the monostate pattern.
|
||||
* Incredibly fast **entity-component system** with its own _pay for what you
|
||||
use_ policy, unconstrained component types with optional pointer stability and
|
||||
|
||||
@@ -48,10 +48,10 @@ also limited to this library only.
|
||||
## ENTT_USE_ATOMIC
|
||||
|
||||
In general, `EnTT` doesn't offer primitives to support multi-threading. Many of
|
||||
the feature can be split over multiple threads without any explicit control and
|
||||
the features can be split over multiple threads without any explicit control and
|
||||
the user is the one who knows if a synchronization point is required.<br/>
|
||||
However, some feature aren't easily accessible to users and are made thread-safe
|
||||
by means of this definition.
|
||||
However, some features aren't easily accessible to users and are made
|
||||
thread-safe by means of this definition.
|
||||
|
||||
## ENTT_ID_TYPE
|
||||
|
||||
|
||||
@@ -435,7 +435,7 @@ their const counterparts) to be iterated by the user.<br/>
|
||||
However, it can happen that a class offers multiple iteration methods or allows
|
||||
users to iterate different sets of _elements_.
|
||||
|
||||
The iterable adaptor is an utility class that makes it easier to use and access
|
||||
The iterable adaptor is a utility class that makes it easier to use and access
|
||||
data in this case.<br/>
|
||||
It accepts a couple of iterators (or an iterator and a sentinel) and offers an
|
||||
_iterable_ object with all the expected methods like `begin`, `end` and whatnot.
|
||||
@@ -770,7 +770,7 @@ tuple-like type and simplify the code at the call site.
|
||||
|
||||
### Constness as
|
||||
|
||||
An utility to easily transfer the constness of a type to another type:
|
||||
A utility to easily transfer the constness of a type to another type:
|
||||
|
||||
```cpp
|
||||
// type is const dst_type because of the constness of src_type
|
||||
@@ -794,7 +794,7 @@ using clazz = entt::member_class_t<Member>;
|
||||
|
||||
### N-th argument
|
||||
|
||||
An utility to quickly find the n-th argument of a function, member function or
|
||||
A utility to quickly find the n-th argument of a function, member function or
|
||||
data member (for blind operations on opaque types):
|
||||
|
||||
```cpp
|
||||
@@ -901,8 +901,8 @@ where constant expressions are required.
|
||||
|
||||
As long as the list remains unchanged, identifiers are also guaranteed to be
|
||||
stable across different runs. In case they have been used in a production
|
||||
environment and a type has to be removed, one can just use a placeholder to left
|
||||
the other identifiers unchanged:
|
||||
environment and a type has to be removed, one can just use a placeholder to
|
||||
leave the other identifiers unchanged:
|
||||
|
||||
```cpp
|
||||
template<typename> struct ignore_type {};
|
||||
|
||||
@@ -487,7 +487,7 @@ At least as long as the `observer` isn't const. This means that the non-const
|
||||
overload of `each` does also reset the underlying data structure before to
|
||||
return to the caller, while the const overload does not for obvious reasons.
|
||||
|
||||
The `collector` is an utility aimed to generate a list of `matcher`s (the actual
|
||||
The `collector` is a utility aimed to generate a list of `matcher`s (the actual
|
||||
rules) to use with an `observer` instead.<br/>
|
||||
There are two types of `matcher`s:
|
||||
|
||||
@@ -1236,7 +1236,7 @@ list is a consequence of a couple of design choices from the past and in the
|
||||
present:
|
||||
|
||||
* First of all, there is no reason to force a user to serialize all the
|
||||
components at once and most of the times it isn't desiderable. As an example,
|
||||
components at once and most of the time it isn't desiderable. As an example,
|
||||
in case the stuff for the HUD in a game is put into the registry for some
|
||||
reasons, its components can be freely discarded during a serialization step
|
||||
because probably the software already knows how to reconstruct them correctly.
|
||||
@@ -1771,7 +1771,7 @@ registry during iterations to get the types iterated by the group itself.
|
||||
|
||||
### Full-owning groups
|
||||
|
||||
A full-owning group is the fastest tool an user can expect to use to iterate
|
||||
A full-owning group is the fastest tool a user can expect to use to iterate
|
||||
multiple components at once. It iterates all the components directly, no
|
||||
indirection required. This type of groups performs more or less as if users are
|
||||
accessing sequentially a bunch of packed arrays of components all sorted
|
||||
@@ -2181,7 +2181,7 @@ See the relevant documentation for more information.
|
||||
## Iterators
|
||||
|
||||
A special mention is needed for the iterators returned by views and groups. Most
|
||||
of the times they meet the requirements of random access iterators, in all cases
|
||||
of the time they meet the requirements of random access iterators, in all cases
|
||||
they meet at least the requirements of forward iterators.<br/>
|
||||
In other terms, they are suitable for use with the parallel algorithms of the
|
||||
standard library. If it's not clear, this is a great thing.
|
||||
|
||||
@@ -62,7 +62,7 @@ These asserts are introduced to help the users but they require to access to the
|
||||
underlying containers and therefore risk ruining the performance in some cases.
|
||||
|
||||
With these changes, debug performance should increase enough for most cases. If
|
||||
you want something more, you can can also switch to an optimization level `O0`
|
||||
you want something more, you can also switch to an optimization level `O0`
|
||||
or preferably `O1`.
|
||||
|
||||
## How can I represent hierarchies with my components?
|
||||
|
||||
@@ -28,7 +28,7 @@
|
||||
# Introduction
|
||||
|
||||
Reflection (or rather, its lack) is a trending topic in the C++ world and a tool
|
||||
that can unlock a lot of interesting feature in the specific case of `EnTT`. I
|
||||
that can unlock a lot of interesting features in the specific case of `EnTT`. I
|
||||
looked for a third-party library that met my needs on the subject, but I always
|
||||
came across some details that I didn't like: macros, being intrusive, too many
|
||||
allocations, and so on.<br/>
|
||||
@@ -49,7 +49,7 @@ compile-time or with custom functions.
|
||||
|
||||
That being said, the examples in the following sections are all based on the
|
||||
`hashed_string` class as provided by this library. Therefore, where an
|
||||
identifier is required, it's likely that an user defined literal is used as
|
||||
identifier is required, it's likely that a user defined literal is used as
|
||||
follows:
|
||||
|
||||
```cpp
|
||||
@@ -349,7 +349,7 @@ meta system in many cases.
|
||||
|
||||
To make a container be recognized as such by the meta system, users are required
|
||||
to provide specializations for either the `meta_sequence_container_traits` class
|
||||
or the `meta_associative_container_traits` class, according with the actual type
|
||||
or the `meta_associative_container_traits` class, according to the actual type
|
||||
of the container.<br/>
|
||||
`EnTT` already exports the specializations for some common classes. In
|
||||
particular:
|
||||
@@ -656,7 +656,7 @@ regardless of the pointed type, no user intervention is required.
|
||||
Meta types also provide a minimal set of information about the nature of the
|
||||
original type in case it's a class template.<br/>
|
||||
By default, this works out of the box and requires no user action. However, it's
|
||||
important to include the header file `template.hpp` to make these information
|
||||
important to include the header file `template.hpp` to make this information
|
||||
available to the compiler when needed.
|
||||
|
||||
Meta template information are easily found:
|
||||
@@ -723,7 +723,7 @@ entt::meta<int>()
|
||||
```
|
||||
|
||||
Repeated for each type eligible to undergo this type of conversions. This is
|
||||
both error prone and repetitive.<br/>
|
||||
both error-prone and repetitive.<br/>
|
||||
Similarly, the language allows users to silently convert unscoped enums to their
|
||||
underlying types and offers what it takes to do the same for scoped enums. It
|
||||
would result in the following if it were to be done explicitly:
|
||||
|
||||
@@ -98,7 +98,7 @@ private:
|
||||
Lambdas and functors can't be used directly with a scheduler for they are not
|
||||
properly defined processes with managed life cycles.<br/>
|
||||
This class helps in filling the gap and turning lambdas and functors into
|
||||
full featured processes usable by a scheduler.
|
||||
full-featured processes usable by a scheduler.
|
||||
|
||||
The function call operator has a signature similar to the one of the `update`
|
||||
function of a process but for the fact that it receives two extra arguments to
|
||||
|
||||
@@ -168,7 +168,8 @@ Therefore, the function type must be declared explicitly for unbound members.
|
||||
The `delegate` class is meant to be used primarily with template arguments.
|
||||
However, as a consequence of its design, it can also offer minimal support for
|
||||
runtime arguments.<br/>
|
||||
When used in this modality, some feature aren't supported though. In particular:
|
||||
When used in this modality, some features aren't supported though. In
|
||||
particular:
|
||||
|
||||
* Curried functions aren't accepted.
|
||||
* Functions with an argument list that differs from that of the delegate aren't
|
||||
@@ -209,7 +210,7 @@ their nuances. The reason is pretty simple: a `delegate` isn't a drop-in
|
||||
replacement for an `std::function`. Instead, it tries to overcome the problems
|
||||
with the latter.<br/>
|
||||
That being said, non-capturing lambda functions are supported, even though some
|
||||
feature aren't available in this case.
|
||||
features aren't available in this case.
|
||||
|
||||
This is a logical consequence of the support for connecting functions at
|
||||
runtime. Therefore, lambda functions undergo the same rules and
|
||||
|
||||
Reference in New Issue
Block a user