BigfootDev/flatbuffers
1
0
Fork 1
mirror of https://github.com/google/flatbuffers.git synced 2026-06-03 20:31:23 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fixed the web pages not scrolling by regenerating with doxygen.

Browse Source 
Change-Id: Id1269f85ec2f522c8d4b0d05f84d050b42d70d60
Tested: on Android
This commit is contained in:
Wouter van Oortmerssen
2014-06-17 11:10:53 -07:00
parent f694bf0913
commit 1485180517
15 changed files with 230 additions and 164 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
docs/html/md__cpp_usage.html
View File

@@ -3,7 +3,7 @@
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.5"/>
<meta name="generator" content="Doxygen 1.8.7"/>
<title>FlatBuffers: Use in C++</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
@@ -32,7 +32,7 @@
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.5 -->
<!-- Generated by Doxygen 1.8.7 -->
</div><!-- top -->
<div id="side-nav" class="ui-resizable side-nav-resizable">
<div id="nav-tree">
@@ -55,49 +55,39 @@ $(document).ready(function(){initNavTree('md__cpp_usage.html','');});
<div class="contents">
<div class="textblock"><p>Assuming you have written a schema using the above language in say <code>mygame.fbs</code> (FlatBuffer Schema, though the extension doesn't matter), you've generated a C++ header called <code>mygame_generated.h</code> using the compiler (e.g. <code>flatc -c mygame.fbs</code>), you can now start using this in your program by including the header. As noted, this header relies on <code>flatbuffers/flatbuffers.h</code>, which should be in your include path.</p>
<h3>Writing in C++</h3>
<p>To start creating a buffer, create an instance of <code>FlatBufferBuilder</code> which will contain the buffer as it grows: </p>
<pre class="fragment">FlatBufferBuilder fbb;
</pre><p>Before we serialize a Monster, we need to first serialize any objects that are contained there-in, i.e. we serialize the data tree using depth first, pre-order traversal. This is generally easy to do on any tree structures. For example: </p>
<pre class="fragment">auto name = fbb.CreateString("MyMonster");
<p>To start creating a buffer, create an instance of <code>FlatBufferBuilder</code> which will contain the buffer as it grows: </p><pre class="fragment">FlatBufferBuilder fbb;
</pre><p>Before we serialize a Monster, we need to first serialize any objects that are contained there-in, i.e. we serialize the data tree using depth first, pre-order traversal. This is generally easy to do on any tree structures. For example: </p><pre class="fragment">auto name = fbb.CreateString("MyMonster");
unsigned char inv[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
auto inventory = fbb.CreateVector(inv, 10);
</pre><p><code>CreateString</code> and <code>CreateVector</code> serialize these two built-in datatypes, and return offsets into the serialized data indicating where they are stored, such that <code>Monster</code> below can refer to them.</p>
<p><code>CreateString</code> can also take an <code>std::string</code>, or a <code>const char *</code> with an explicit length, and is suitable for holding UTF-8 and binary data if needed.</p>
<p><code>CreateVector</code> can also take an <code>std::vector</code>. The offset it returns is typed, i.e. can only be used to set fields of the correct type below. To create a vector of struct objects (which will be stored as contiguous memory in the buffer, use <code>CreateVectorOfStructs</code> instead. </p>
<pre class="fragment">Vec3 vec(1, 2, 3);
<p><code>CreateVector</code> can also take an <code>std::vector</code>. The offset it returns is typed, i.e. can only be used to set fields of the correct type below. To create a vector of struct objects (which will be stored as contiguous memory in the buffer, use <code>CreateVectorOfStructs</code> instead. </p><pre class="fragment">Vec3 vec(1, 2, 3);
</pre><p><code>Vec3</code> is the first example of code from our generated header. Structs (unlike tables) translate to simple structs in C++, so we can construct them in a familiar way.</p>
<p>We have now serialized the non-scalar components of of the monster example, so we could create the monster something like this: </p>
<pre class="fragment">auto mloc = CreateMonster(fbb, &amp;vec, 150, 80, name, inventory, Color_Red, Offset&lt;void&gt;(0), Any_NONE);
<p>We have now serialized the non-scalar components of of the monster example, so we could create the monster something like this: </p><pre class="fragment">auto mloc = CreateMonster(fbb, &amp;vec, 150, 80, name, inventory, Color_Red, Offset&lt;void&gt;(0), Any_NONE);
</pre><p>Note that we're passing <code>150</code> for the <code>mana</code> field, which happens to be the default value: this means the field will not actually be written to the buffer, since we'll get that value anyway when we query it. This is a nice space savings, since it is very common for fields to be at their default. It means we also don't need to be scared to add fields only used in a minority of cases, since they won't bloat up the buffer sizes if they're not actually used.</p>
<p>We do something similarly for the union field <code>test</code> by specifying a <code>0</code> offset and the <code>NONE</code> enum value (part of every union) to indicate we don't actually want to write this field.</p>
<p>Tables (like <code>Monster</code>) give you full flexibility on what fields you write (unlike <code>Vec3</code>, which always has all fields set because it is a <code>struct</code>). If you want even more control over this (i.e. skip fields even when they are not default), instead of the convenient <code>CreateMonster</code> call we can also build the object field-by-field manually: </p>
<pre class="fragment">MonsterBuilder mb(fbb);
<p>Tables (like <code>Monster</code>) give you full flexibility on what fields you write (unlike <code>Vec3</code>, which always has all fields set because it is a <code>struct</code>). If you want even more control over this (i.e. skip fields even when they are not default), instead of the convenient <code>CreateMonster</code> call we can also build the object field-by-field manually: </p><pre class="fragment">MonsterBuilder mb(fbb);
mb.add_pos(&amp;vec);
mb.add_hp(80);
mb.add_name(name);
mb.add_inventory(inventory);
auto mloc = mb.Finish();
</pre><p>We start with a temporary helper class <code>MonsterBuilder</code> (which is defined in our generated code also), then call the various <code>add_</code> methods to set fields, and <code>Finish</code> to complete the object. This is pretty much the same code as you find inside <code>CreateMonster</code>, except we're leaving out a few fields. Fields may also be added in any order, though orderings with fields of the same size adjacent to each other most efficient in size, due to alignment. You should not nest these Builder classes (serialize your data in pre-order).</p>
<p>Regardless of whether you used <code>CreateMonster</code> or <code>MonsterBuilder</code>, you now have an offset to the root of your data, and you can finish the buffer using: </p>
<pre class="fragment">fbb.Finish(mloc);
<p>Regardless of whether you used <code>CreateMonster</code> or <code>MonsterBuilder</code>, you now have an offset to the root of your data, and you can finish the buffer using: </p><pre class="fragment">fbb.Finish(mloc);
</pre><p>The buffer is now ready to be stored somewhere, sent over the network, be compressed, or whatever you'd like to do with it. You can access the start of the buffer with <code>fbb.GetBufferPointer()</code>, and it's size from <code>fbb.GetSize()</code>.</p>
<p><code>samples/sample_binary.cpp</code> is a complete code sample similar to the code above, that also includes the reading code below.</p>
<h3>Reading in C++</h3>
<p>If you've received a buffer from somewhere (disk, network, etc.) you can directly start traversing it using: </p>
<pre class="fragment">auto monster = GetMonster(buffer_pointer);
</pre><p><code>monster</code> is of type <code>Monster *</code>, and points to somewhere inside your buffer. If you look in your generated header, you'll see it has convenient accessors for all fields, e.g. </p>
<pre class="fragment">assert(monster-&gt;hp() == 80);
<p>If you've received a buffer from somewhere (disk, network, etc.) you can directly start traversing it using: </p><pre class="fragment">auto monster = GetMonster(buffer_pointer);
</pre><p><code>monster</code> is of type <code>Monster *</code>, and points to somewhere inside your buffer. If you look in your generated header, you'll see it has convenient accessors for all fields, e.g. </p><pre class="fragment">assert(monster-&gt;hp() == 80);
assert(monster-&gt;mana() == 150); // default
assert(strcmp(monster-&gt;name()-&gt;c_str(), "MyMonster") == 0);
</pre><p>These should all be true. Note that we never stored a <code>mana</code> value, so it will return the default.</p>
<p>To access sub-objects, in this case the <code>Vec3</code>: </p>
<pre class="fragment">auto pos = monster-&gt;pos();
<p>To access sub-objects, in this case the <code>Vec3</code>: </p><pre class="fragment">auto pos = monster-&gt;pos();
assert(pos);
assert(pos-&gt;z() == 3);
</pre><p>If we had not set the <code>pos</code> field during serialization, it would be <code>NULL</code>.</p>
<p>Similarly, we can access elements of the inventory array: </p>
<pre class="fragment">auto inv = monster-&gt;inventory();
<p>Similarly, we can access elements of the inventory array: </p><pre class="fragment">auto inv = monster-&gt;inventory();
assert(inv);
assert(inv-&gt;Get(9) == 9);
</pre><h3>Direct memory access</h3>
@@ -110,17 +100,14 @@ assert(inv-&gt;Get(9) == 9);
<p>Another reason might be that you already have a lot of data in JSON format, or a tool that generates JSON, and if you can write a schema for it, this will provide you an easy way to use that data directly.</p>
<p>There are two ways to use text formats:</p>
<h3>Using the compiler as a conversion tool</h3>
<p>This is the preferred path, as it doesn't require you to add any new code to your program, and is maximally efficient since you can ship with binary data. The disadvantage is that it is an extra step for your users/developers to perform, though you might be able to automate it. </p>
<pre class="fragment">flatc -b myschema.fbs mydata.json
<p>This is the preferred path, as it doesn't require you to add any new code to your program, and is maximally efficient since you can ship with binary data. The disadvantage is that it is an extra step for your users/developers to perform, though you might be able to automate it. </p><pre class="fragment">flatc -b myschema.fbs mydata.json
</pre><p>This will generate the binary file <code>mydata_wire.bin</code> which can be loaded as before.</p>
<h3>Making your program capable of loading text directly</h3>
<p>This gives you maximum flexibility. You could even opt to support both, i.e. check for both files, and regenerate the binary from text when required, otherwise just load the binary.</p>
<p>This option is currently only available for C++, or Java through JNI.</p>
<p>As mentioned in the section "Building" above, this technique requires you to link a few more files into your program, and you'll want to include <code>flatbuffers/idl.h</code>.</p>
<p>Load text (either a schema or json) into an in-memory buffer (there is a convenient <code>LoadFile()</code> utility function in <code>flatbuffers/util.h</code> if you wish). Construct a parser: </p>
<pre class="fragment">flatbuffers::Parser parser;
</pre><p>Now you can parse any number of text files in sequence: </p>
<pre class="fragment">parser.Parse(text_file.c_str());
<p>Load text (either a schema or json) into an in-memory buffer (there is a convenient <code>LoadFile()</code> utility function in <code>flatbuffers/util.h</code> if you wish). Construct a parser: </p><pre class="fragment">flatbuffers::Parser parser;
</pre><p>Now you can parse any number of text files in sequence: </p><pre class="fragment">parser.Parse(text_file.c_str());
</pre><p>This works similarly to how the command-line compiler works: a sequence of files parsed by the same <code>Parser</code> object allow later files to reference definitions in earlier files. Typically this means you first load a schema file (which populates <code>Parser</code> with definitions), followed by one or more JSON files.</p>
<p>If there were any parsing errors, <code>Parse</code> will return <code>false</code>, and <code>Parser::err</code> contains a human readable error string with a line number etc, which you should present to the creator of that file.</p>
<p>After each JSON file, the <code>Parser::fbb</code> member variable is the <code>FlatBufferBuilder</code> that contains the binary buffer version of that file, that you can access as described above.</p>