Various documentation improvements.
Change-Id: Iacea45ae0f602f49e46de472286a7a77ee20c301
This commit is contained in:
parent
d426890b92
commit
ea592296b8
|
@ -87,15 +87,16 @@ $(document).ready(function(){initNavTree('md__go_usage.html','');});
|
||||||
<div class="line">example.MonsterAddTest(builder, mon2)</div>
|
<div class="line">example.MonsterAddTest(builder, mon2)</div>
|
||||||
<div class="line">example.MonsterAddTest4(builder, test4s)</div>
|
<div class="line">example.MonsterAddTest4(builder, test4s)</div>
|
||||||
<div class="line">mon := example.MonsterEnd(builder)</div>
|
<div class="line">mon := example.MonsterEnd(builder)</div>
|
||||||
</div><!-- fragment --><p>Unlike C++, Go does not support table creation functions like 'createMonster()'. This is to create the buffer without using temporary object allocation (since the <code>Vec3</code> is an inline component of <code>Monster</code>, it has to be created right where it is added, whereas the name and the inventory are not inline). Structs do have convenient methods that allow you to construct them in one call. These also have arguments for nested structs, e.g. if a struct has a field <code>a</code> and a nested struct field <code>b</code> (which has fields <code>c</code> and <code>d</code>), then the arguments will be <code>a</code>, <code>c</code> and <code>d</code>.</p>
|
</div><!-- fragment --><p>Unlike C++, Go does not support table creation functions like 'createMonster()'. This is to create the buffer without using temporary object allocation (since the <code>Vec3</code> is an inline component of <code>Monster</code>, it has to be created right where it is added, whereas the name and the inventory are not inline, and <b>must</b> be created outside of the table creation sequence). Structs do have convenient methods that allow you to construct them in one call. These also have arguments for nested structs, e.g. if a struct has a field <code>a</code> and a nested struct field <code>b</code> (which has fields <code>c</code> and <code>d</code>), then the arguments will be <code>a</code>, <code>c</code> and <code>d</code>.</p>
|
||||||
<p>Vectors also use this start/end pattern to allow vectors of both scalar types and structs:</p>
|
<p>Vectors also use this start/end pattern to allow vectors of both scalar types and structs:</p>
|
||||||
<div class="fragment"><div class="line">example.MonsterStartInventoryVector(builder, 5)</div>
|
<div class="fragment"><div class="line">example.MonsterStartInventoryVector(builder, 5)</div>
|
||||||
<div class="line"><span class="keywordflow">for</span> i := 4; i >= 0; i-- {</div>
|
<div class="line"><span class="keywordflow">for</span> i := 4; i >= 0; i-- {</div>
|
||||||
<div class="line"> builder.PrependByte(byte(i))</div>
|
<div class="line"> builder.PrependByte(byte(i))</div>
|
||||||
<div class="line">}</div>
|
<div class="line">}</div>
|
||||||
<div class="line">inv := builder.EndVector(5)</div>
|
<div class="line">inv := builder.EndVector(5)</div>
|
||||||
</div><!-- fragment --><p>The generated method 'StartInventoryVector' is provided as a convenience function which calls 'StartVector' with the correct element size of the vector type which in this case is 'ubyte' or 1 byte per vector element. You pass the number of elements you want to write. You write the elements backwards since the buffer is being constructed back to front.</p>
|
</div><!-- fragment --><p>The generated method 'StartInventoryVector' is provided as a convenience function which calls 'StartVector' with the correct element size of the vector type which in this case is 'ubyte' or 1 byte per vector element. You pass the number of elements you want to write. You write the elements backwards since the buffer is being constructed back to front. You then pass <code>inv</code> to the corresponding <code>Add</code> call when you construct the table containing it afterwards.</p>
|
||||||
<p>There are <code>Prepend</code> functions for all the scalar types. You use <code>PrependUOffset</code> for any previously constructed objects (such as other tables, strings, vectors). For structs, you use the appropriate <code>create</code> function in-line, as shown above in the <code>Monster</code> example.</p>
|
<p>There are <code>Prepend</code> functions for all the scalar types. You use <code>PrependUOffset</code> for any previously constructed objects (such as other tables, strings, vectors). For structs, you use the appropriate <code>create</code> function in-line, as shown above in the <code>Monster</code> example.</p>
|
||||||
|
<p>Once you're done constructing a buffer, you call <code>Finish</code> with the root object offset (<code>mon</code> in the example above). Your data now resides in Builder.Bytes. Important to note is that the real data starts at the index indicated by Head(), for Offset() bytes (this is because the buffer is constructed backwards). If you wanted to read the buffer right after creating it (using <code>GetRootAsMonster</code> above), the second argument, instead of <code>0</code> would thus also be <code>Head()</code>.</p>
|
||||||
<h2>Text Parsing</h2>
|
<h2>Text Parsing</h2>
|
||||||
<p>There currently is no support for parsing text (Schema's and JSON) directly from Go, though you could use the C++ parser through cgo. Please see the C++ documentation for more on text parsing. </p>
|
<p>There currently is no support for parsing text (Schema's and JSON) directly from Go, though you could use the C++ parser through cgo. Please see the C++ documentation for more on text parsing. </p>
|
||||||
</div></div><!-- contents -->
|
</div></div><!-- contents -->
|
||||||
|
|
|
@ -94,7 +94,7 @@ $(document).ready(function(){initNavTree('md__java_usage.html','');});
|
||||||
<div class="fragment"><div class="line">Monster.startInventoryVector(fbb, 5);</div>
|
<div class="fragment"><div class="line">Monster.startInventoryVector(fbb, 5);</div>
|
||||||
<div class="line"><span class="keywordflow">for</span> (byte i = 4; i >=0; i--) fbb.addByte(i);</div>
|
<div class="line"><span class="keywordflow">for</span> (byte i = 4; i >=0; i--) fbb.addByte(i);</div>
|
||||||
<div class="line"><span class="keywordtype">int</span> inv = fbb.endVector();</div>
|
<div class="line"><span class="keywordtype">int</span> inv = fbb.endVector();</div>
|
||||||
</div><!-- fragment --><p>You can use the generated method <code>startInventoryVector</code> to conveniently call <code>startVector</code> with the right element size. You pass the number of elements you want to write. Note how you write the elements backwards since the buffer is being constructed back to front.</p>
|
</div><!-- fragment --><p>You can use the generated method <code>startInventoryVector</code> to conveniently call <code>startVector</code> with the right element size. You pass the number of elements you want to write. Note how you write the elements backwards since the buffer is being constructed back to front. You then pass <code>inv</code> to the corresponding <code>Add</code> call when you construct the table containing it afterwards.</p>
|
||||||
<p>There are <code>add</code> functions for all the scalar types. You use <code>addOffset</code> for any previously constructed objects (such as other tables, strings, vectors). For structs, you use the appropriate <code>create</code> function in-line, as shown above in the <code>Monster</code> example.</p>
|
<p>There are <code>add</code> functions for all the scalar types. You use <code>addOffset</code> for any previously constructed objects (such as other tables, strings, vectors). For structs, you use the appropriate <code>create</code> function in-line, as shown above in the <code>Monster</code> example.</p>
|
||||||
<p>To finish the buffer, call:</p>
|
<p>To finish the buffer, call:</p>
|
||||||
<div class="fragment"><div class="line">Monster.finishMonsterBuffer(fbb, mon);</div>
|
<div class="fragment"><div class="line">Monster.finishMonsterBuffer(fbb, mon);</div>
|
||||||
|
|
|
@ -112,7 +112,7 @@ root_type Monster;
|
||||||
<h3>Namespaces</h3>
|
<h3>Namespaces</h3>
|
||||||
<p>These will generate the corresponding namespace in C++ for all helper code, and packages in Java. You can use <code>.</code> to specify nested namespaces / packages.</p>
|
<p>These will generate the corresponding namespace in C++ for all helper code, and packages in Java. You can use <code>.</code> to specify nested namespaces / packages.</p>
|
||||||
<h3>Includes</h3>
|
<h3>Includes</h3>
|
||||||
<p>You can include other schemas files in your current one, e.g.: </p><pre class="fragment">include "mydefinitions.fbs"
|
<p>You can include other schemas files in your current one, e.g.: </p><pre class="fragment">include "mydefinitions.fbs";
|
||||||
</pre><p>This makes it easier to refer to types defined elsewhere. <code>include</code> automatically ensures each file is parsed just once, even when referred to more than once.</p>
|
</pre><p>This makes it easier to refer to types defined elsewhere. <code>include</code> automatically ensures each file is parsed just once, even when referred to more than once.</p>
|
||||||
<p>When using the <code>flatc</code> compiler to generate code for schema definitions, only definitions in the current file will be generated, not those from the included files (those you still generate separately).</p>
|
<p>When using the <code>flatc</code> compiler to generate code for schema definitions, only definitions in the current file will be generated, not those from the included files (those you still generate separately).</p>
|
||||||
<h3>Root type</h3>
|
<h3>Root type</h3>
|
||||||
|
@ -128,7 +128,7 @@ root_type Monster;
|
||||||
</pre><h3>Comments & documentation</h3>
|
</pre><h3>Comments & documentation</h3>
|
||||||
<p>May be written as in most C-based languages. Additionally, a triple comment (<code>///</code>) on a line by itself signals that a comment is documentation for whatever is declared on the line after it (table/struct/field/enum/union/element), and the comment is output in the corresponding C++ code. Multiple such lines per item are allowed.</p>
|
<p>May be written as in most C-based languages. Additionally, a triple comment (<code>///</code>) on a line by itself signals that a comment is documentation for whatever is declared on the line after it (table/struct/field/enum/union/element), and the comment is output in the corresponding C++ code. Multiple such lines per item are allowed.</p>
|
||||||
<h3>Attributes</h3>
|
<h3>Attributes</h3>
|
||||||
<p>Attributes may be attached to a declaration, behind a field, or after the name of a table/struct/enum/union. These may either have a value or not. Some attributes like <code>deprecated</code> are understood by the compiler, others are simply ignored (like <code>priority</code>), but are available to query if you parse the schema at runtime. This is useful if you write your own code generators/editors etc., and you wish to add additional information specific to your tool (such as a help text).</p>
|
<p>Attributes may be attached to a declaration, behind a field, or after the name of a table/struct/enum/union. These may either have a value or not. Some attributes like <code>deprecated</code> are understood by the compiler, others are simply ignored (like <code>priority</code> in the example above), but are available to query if you parse the schema at runtime. This is useful if you write your own code generators/editors etc., and you wish to add additional information specific to your tool (such as a help text).</p>
|
||||||
<p>Current understood attributes:</p>
|
<p>Current understood attributes:</p>
|
||||||
<ul>
|
<ul>
|
||||||
<li><code>id: n</code> (on a table field): manually set the field identifier to <code>n</code>. If you use this attribute, you must use it on ALL fields of this table, and the numbers must be a contiguous range from 0 onwards. Additionally, since a union type effectively adds two fields, its id must be that of the second field (the first field is the type field and not explicitly declared in the schema). For example, if the last field before the union field had id 6, the union field should have id 8, and the unions type field will implicitly be 7. IDs allow the fields to be placed in any order in the schema. When a new field is added to the schema is must use the next available ID.</li>
|
<li><code>id: n</code> (on a table field): manually set the field identifier to <code>n</code>. If you use this attribute, you must use it on ALL fields of this table, and the numbers must be a contiguous range from 0 onwards. Additionally, since a union type effectively adds two fields, its id must be that of the second field (the first field is the type field and not explicitly declared in the schema). For example, if the last field before the union field had id 6, the union field should have id 8, and the unions type field will implicitly be 7. IDs allow the fields to be placed in any order in the schema. When a new field is added to the schema is must use the next available ID.</li>
|
||||||
|
@ -137,6 +137,7 @@ root_type Monster;
|
||||||
<li><code>original_order</code> (on a table): since elements in a table do not need to be stored in any particular order, they are often optimized for space by sorting them to size. This attribute stops that from happening.</li>
|
<li><code>original_order</code> (on a table): since elements in a table do not need to be stored in any particular order, they are often optimized for space by sorting them to size. This attribute stops that from happening.</li>
|
||||||
<li><code>force_align: size</code> (on a struct): force the alignment of this struct to be something higher than what it is naturally aligned to. Causes these structs to be aligned to that amount inside a buffer, IF that buffer is allocated with that alignment (which is not necessarily the case for buffers accessed directly inside a <code>FlatBufferBuilder</code>).</li>
|
<li><code>force_align: size</code> (on a struct): force the alignment of this struct to be something higher than what it is naturally aligned to. Causes these structs to be aligned to that amount inside a buffer, IF that buffer is allocated with that alignment (which is not necessarily the case for buffers accessed directly inside a <code>FlatBufferBuilder</code>).</li>
|
||||||
<li><code>bit_flags</code> (on an enum): the values of this field indicate bits, meaning that any value N specified in the schema will end up representing 1<<N, or if you don't specify values at all, you'll get the sequence 1, 2, 4, 8, ...</li>
|
<li><code>bit_flags</code> (on an enum): the values of this field indicate bits, meaning that any value N specified in the schema will end up representing 1<<N, or if you don't specify values at all, you'll get the sequence 1, 2, 4, 8, ...</li>
|
||||||
|
<li><code>nested_flatbuffer: table_name</code> (on a field): this indicates that the field (which must be a vector of ubyte) contains flatbuffer data, for which the root type is given by <code>table_name</code>. The generated code will then produce a convenient accessor for the nested FlatBuffer.</li>
|
||||||
</ul>
|
</ul>
|
||||||
<h2>JSON Parsing</h2>
|
<h2>JSON Parsing</h2>
|
||||||
<p>The same parser that parses the schema declarations above is also able to parse JSON objects that conform to this schema. So, unlike other JSON parsers, this parser is strongly typed, and parses directly into a FlatBuffer (see the compiler documentation on how to do this from the command line, or the C++ documentation on how to do this at runtime).</p>
|
<p>The same parser that parses the schema declarations above is also able to parse JSON objects that conform to this schema. So, unlike other JSON parsers, this parser is strongly typed, and parses directly into a FlatBuffer (see the compiler documentation on how to do this from the command line, or the C++ documentation on how to do this at runtime).</p>
|
||||||
|
|
|
@ -75,7 +75,8 @@ Unlike C++, Go does not support table creation functions like 'createMonster()'.
|
||||||
This is to create the buffer without
|
This is to create the buffer without
|
||||||
using temporary object allocation (since the `Vec3` is an inline component of
|
using temporary object allocation (since the `Vec3` is an inline component of
|
||||||
`Monster`, it has to be created right where it is added, whereas the name and
|
`Monster`, it has to be created right where it is added, whereas the name and
|
||||||
the inventory are not inline).
|
the inventory are not inline, and **must** be created outside of the table
|
||||||
|
creation sequence).
|
||||||
Structs do have convenient methods that allow you to construct them in one call.
|
Structs do have convenient methods that allow you to construct them in one call.
|
||||||
These also have arguments for nested structs, e.g. if a struct has a field `a`
|
These also have arguments for nested structs, e.g. if a struct has a field `a`
|
||||||
and a nested struct field `b` (which has fields `c` and `d`), then the arguments
|
and a nested struct field `b` (which has fields `c` and `d`), then the arguments
|
||||||
|
@ -97,13 +98,22 @@ function which calls 'StartVector' with the correct element size of the vector
|
||||||
type which in this case is 'ubyte' or 1 byte per vector element.
|
type which in this case is 'ubyte' or 1 byte per vector element.
|
||||||
You pass the number of elements you want to write.
|
You pass the number of elements you want to write.
|
||||||
You write the elements backwards since the buffer
|
You write the elements backwards since the buffer
|
||||||
is being constructed back to front.
|
is being constructed back to front. You then pass `inv` to the corresponding
|
||||||
|
`Add` call when you construct the table containing it afterwards.
|
||||||
|
|
||||||
There are `Prepend` functions for all the scalar types. You use
|
There are `Prepend` functions for all the scalar types. You use
|
||||||
`PrependUOffset` for any previously constructed objects (such as other tables,
|
`PrependUOffset` for any previously constructed objects (such as other tables,
|
||||||
strings, vectors). For structs, you use the appropriate `create` function
|
strings, vectors). For structs, you use the appropriate `create` function
|
||||||
in-line, as shown above in the `Monster` example.
|
in-line, as shown above in the `Monster` example.
|
||||||
|
|
||||||
|
Once you're done constructing a buffer, you call `Finish` with the root object
|
||||||
|
offset (`mon` in the example above). Your data now resides in Builder.Bytes.
|
||||||
|
Important to note is that the real data starts at the index indicated by Head(),
|
||||||
|
for Offset() bytes (this is because the buffer is constructed backwards).
|
||||||
|
If you wanted to read the buffer right after creating it (using
|
||||||
|
`GetRootAsMonster` above), the second argument, instead of `0` would thus
|
||||||
|
also be `Head()`.
|
||||||
|
|
||||||
## Text Parsing
|
## Text Parsing
|
||||||
|
|
||||||
There currently is no support for parsing text (Schema's and JSON) directly
|
There currently is no support for parsing text (Schema's and JSON) directly
|
||||||
|
|
|
@ -125,7 +125,8 @@ does not sit in an array, you can also use the start/end pattern:
|
||||||
You can use the generated method `startInventoryVector` to conveniently call
|
You can use the generated method `startInventoryVector` to conveniently call
|
||||||
`startVector` with the right element size. You pass the number of
|
`startVector` with the right element size. You pass the number of
|
||||||
elements you want to write. Note how you write the elements backwards since
|
elements you want to write. Note how you write the elements backwards since
|
||||||
the buffer is being constructed back to front.
|
the buffer is being constructed back to front. You then pass `inv` to the
|
||||||
|
corresponding `Add` call when you construct the table containing it afterwards.
|
||||||
|
|
||||||
There are `add` functions for all the scalar types. You use `addOffset` for
|
There are `add` functions for all the scalar types. You use `addOffset` for
|
||||||
any previously constructed objects (such as other tables, strings, vectors).
|
any previously constructed objects (such as other tables, strings, vectors).
|
||||||
|
|
|
@ -145,7 +145,7 @@ packages.
|
||||||
|
|
||||||
You can include other schemas files in your current one, e.g.:
|
You can include other schemas files in your current one, e.g.:
|
||||||
|
|
||||||
include "mydefinitions.fbs"
|
include "mydefinitions.fbs";
|
||||||
|
|
||||||
This makes it easier to refer to types defined elsewhere. `include`
|
This makes it easier to refer to types defined elsewhere. `include`
|
||||||
automatically ensures each file is parsed just once, even when referred to
|
automatically ensures each file is parsed just once, even when referred to
|
||||||
|
@ -211,8 +211,8 @@ in the corresponding C++ code. Multiple such lines per item are allowed.
|
||||||
Attributes may be attached to a declaration, behind a field, or after
|
Attributes may be attached to a declaration, behind a field, or after
|
||||||
the name of a table/struct/enum/union. These may either have a value or
|
the name of a table/struct/enum/union. These may either have a value or
|
||||||
not. Some attributes like `deprecated` are understood by the compiler,
|
not. Some attributes like `deprecated` are understood by the compiler,
|
||||||
others are simply ignored (like `priority`), but are available to query
|
others are simply ignored (like `priority` in the example above), but are
|
||||||
if you parse the schema at runtime.
|
available to query if you parse the schema at runtime.
|
||||||
This is useful if you write your own code generators/editors etc., and
|
This is useful if you write your own code generators/editors etc., and
|
||||||
you wish to add additional information specific to your tool (such as a
|
you wish to add additional information specific to your tool (such as a
|
||||||
help text).
|
help text).
|
||||||
|
@ -254,6 +254,10 @@ Current understood attributes:
|
||||||
meaning that any value N specified in the schema will end up
|
meaning that any value N specified in the schema will end up
|
||||||
representing 1<<N, or if you don't specify values at all, you'll get
|
representing 1<<N, or if you don't specify values at all, you'll get
|
||||||
the sequence 1, 2, 4, 8, ...
|
the sequence 1, 2, 4, 8, ...
|
||||||
|
- `nested_flatbuffer: table_name` (on a field): this indicates that the field
|
||||||
|
(which must be a vector of ubyte) contains flatbuffer data, for which the
|
||||||
|
root type is given by `table_name`. The generated code will then produce
|
||||||
|
a convenient accessor for the nested FlatBuffer.
|
||||||
|
|
||||||
## JSON Parsing
|
## JSON Parsing
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue