mirror of
https://github.com/google/flatbuffers.git
synced 2026-06-01 19:58:15 +00:00
Fix typos in docs (#6829)
This commit is contained in:
@@ -7,7 +7,7 @@ The `flatcc` C schema compiler can generate code offline as well as
|
||||
online via a C library. It can also generate buffer verifiers and fast
|
||||
JSON parsers, printers.
|
||||
|
||||
Great care has been taken to ensure compatibily with the main `flatc`
|
||||
Great care has been taken to ensure compatibility with the main `flatc`
|
||||
project.
|
||||
|
||||
## General Documention
|
||||
|
||||
@@ -85,7 +85,7 @@ referred to by offset.
|
||||
|
||||
They start with an `soffset_t` to a vtable. This is a signed version of
|
||||
`uoffset_t`, since vtables may be stored anywhere relative to the object.
|
||||
This offset is substracted (not added) from the object start to arrive at
|
||||
This offset is subtracted (not added) from the object start to arrive at
|
||||
the vtable start. This offset is followed by all the
|
||||
fields as aligned scalars (or offsets). Unlike structs, not all fields
|
||||
need to be present. There is no set order and layout. A table may contain
|
||||
@@ -435,7 +435,7 @@ The keys vector is a typed vector of keys. Both the keys and corresponding
|
||||
values *have* to be stored in sorted order (as determined by `strcmp`), such
|
||||
that lookups can be made using binary search.
|
||||
|
||||
The reason the key vector is a seperate structure from the value vector is
|
||||
The reason the key vector is a separate structure from the value vector is
|
||||
such that it can be shared between multiple value vectors, and also to
|
||||
allow it to be treated as its own individual vector in code.
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ https://www.npmjs.com/package/flatbuffers. To use it from sources:
|
||||
1. In your project, install it as a normal dependency, using the flatbuffers
|
||||
folder as the source.
|
||||
|
||||
## Using the FlatBuffers JavaScript libary
|
||||
## Using the FlatBuffers JavaScript library
|
||||
|
||||
*Note: See [Tutorial](@ref flatbuffers_guide_tutorial) for a more in-depth
|
||||
example of how to use FlatBuffers.*
|
||||
|
||||
@@ -36,7 +36,7 @@ The test code itself is located in
|
||||
[integration_test.rs](https://github.com/google/flatbuffers/blob/master/tests/rust_usage_test/tests/integration_test.rs)
|
||||
|
||||
This test file requires `flatc` to be present. To review how to build the project,
|
||||
please read the [Building](@ref flatbuffers_guide_building) documenation.
|
||||
please read the [Building](@ref flatbuffers_guide_building) documentation.
|
||||
|
||||
To run the tests, execute `RustTest.sh` from the `flatbuffers/tests` directory.
|
||||
For example, on [Linux](https://en.wikipedia.org/wiki/Linux), you would simply
|
||||
|
||||
@@ -490,7 +490,7 @@ as much as possible such that you can use tables where you might be
|
||||
tempted to use a dictionary.
|
||||
|
||||
Similarly, strings as values should only be used when they are
|
||||
truely open-ended. If you can, always use an enum instead.
|
||||
truly open-ended. If you can, always use an enum instead.
|
||||
|
||||
FlatBuffers doesn't have inheritance, so the way to represent a set
|
||||
of related data structures is a union. Unions do have a cost however,
|
||||
|
||||
@@ -231,7 +231,7 @@ fields, such as `mana:short = 150`. If unspecified, scalar fields (like `int`,
|
||||
`uint`, or `float`) will be given a default of `0` while strings and tables will
|
||||
be given a default of `null`. Another thing to note is the line `friendly:bool =
|
||||
false (deprecated);`. Since you cannot delete fields from a `table` (to support
|
||||
backwards compatability), you can set fields as `deprecated`, which will prevent
|
||||
backwards compatibility), you can set fields as `deprecated`, which will prevent
|
||||
the generation of accessors for this field in the generated code. Be careful
|
||||
when using `deprecated`, however, as it may break legacy code that used this
|
||||
accessor.
|
||||
@@ -1090,7 +1090,7 @@ traversal. This is generally easy to do on any tree structures.
|
||||
</div>
|
||||
<div class="language-lua">
|
||||
~~~{.py}
|
||||
-- Serialize a name for our mosnter, called 'orc'
|
||||
-- Serialize a name for our monster, called 'orc'
|
||||
local name = builder:CreateString("Orc")
|
||||
|
||||
-- Create a `vector` representing the inventory of the Orc. Each number
|
||||
|
||||
@@ -26,7 +26,7 @@ flatbuffers/blob/master/tests/TypeScriptTest.sh) shell script.
|
||||
|
||||
*Note: The TypeScript test file requires [Node.js](https://nodejs.org/en/).*
|
||||
|
||||
## Using the FlatBuffers TypeScript libary
|
||||
## Using the FlatBuffers TypeScript library
|
||||
|
||||
*Note: See [Tutorial](@ref flatbuffers_guide_tutorial) for a more in-depth
|
||||
example of how to use FlatBuffers in TypeScript.*
|
||||
|
||||
@@ -20,7 +20,7 @@ and locality.
|
||||
If it would be possible to do serialization with no temporary objects,
|
||||
no additional allocation, no copying, and good locality, this could be
|
||||
of great value. The reason serialization systems usually don't manage
|
||||
this is because it goes counter to forwards/backwards compatability, and
|
||||
this is because it goes counter to forwards/backwards compatibility, and
|
||||
platform specifics like endianness and alignment.
|
||||
|
||||
FlatBuffers is what you get if you try anyway.
|
||||
|
||||
Reference in New Issue
Block a user