BigfootDev/flatbuffers
1
0
Fork 1
mirror of https://github.com/google/flatbuffers.git synced 2026-06-20 05:55:05 +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

34
docs/html/md__internals.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: FlatBuffer Internals</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">
@@ -76,15 +76,13 @@ $(document).ready(function(){initNavTree('md__internals.html','');});
<h3>Construction</h3>
<p>The current implementation constructs these buffers backwards, since that significantly reduces the amount of bookkeeping and simplifies the construction API.</p>
<h3>Code example</h3>
<p>Here's an example of the code that gets generated for the <code>samples/monster.fbs</code>. What follows is the entire file, broken up by comments: </p>
<pre class="fragment">// automatically generated, do not modify
<p>Here's an example of the code that gets generated for the <code>samples/monster.fbs</code>. What follows is the entire file, broken up by comments: </p><pre class="fragment">// automatically generated, do not modify
#include "flatbuffers/flatbuffers.h"
namespace MyGame {
namespace Sample {
</pre><p>Nested namespace support. </p>
<pre class="fragment">enum {
</pre><p>Nested namespace support. </p><pre class="fragment">enum {
Color_Red = 0,
Color_Green = 1,
Color_Blue = 2,
@@ -96,8 +94,7 @@ inline const char **EnumNamesColor() {
}
inline const char *EnumNameColor(int e) { return EnumNamesColor()[e]; }
</pre><p>Enums and convenient reverse lookup. </p>
<pre class="fragment">enum {
</pre><p>Enums and convenient reverse lookup. </p><pre class="fragment">enum {
Any_NONE = 0,
Any_Monster = 1,
};
@@ -108,11 +105,9 @@ inline const char **EnumNamesAny() {
}
inline const char *EnumNameAny(int e) { return EnumNamesAny()[e]; }
</pre><p>Unions share a lot with enums. </p>
<pre class="fragment">struct Vec3;
</pre><p>Unions share a lot with enums. </p><pre class="fragment">struct Vec3;
struct Monster;
</pre><p>Predeclare all datatypes since there may be circular references. </p>
<pre class="fragment">MANUALLY_ALIGNED_STRUCT(4) Vec3 {
</pre><p>Predeclare all datatypes since there may be circular references. </p><pre class="fragment">MANUALLY_ALIGNED_STRUCT(4) Vec3 {
private:
float x_;
float y_;
@@ -127,8 +122,7 @@ struct Monster;
float z() const { return flatbuffers::EndianScalar(z_); }
};
STRUCT_END(Vec3, 12);
</pre><p>These ugly macros do a couple of things: they turn off any padding the compiler might normally do, since we add padding manually (though none in this example), and they enforce alignment chosen by FlatBuffers. This ensures the layout of this struct will look the same regardless of compiler and platform. Note that the fields are private: this is because these store little endian scalars regardless of platform (since this is part of the serialized data). <code>EndianScalar</code> then converts back and forth, which is a no-op on all current mobile and desktop platforms, and a single machine instruction on the few remaining big endian platforms. </p>
<pre class="fragment">struct Monster : private flatbuffers::Table {
</pre><p>These ugly macros do a couple of things: they turn off any padding the compiler might normally do, since we add padding manually (though none in this example), and they enforce alignment chosen by FlatBuffers. This ensures the layout of this struct will look the same regardless of compiler and platform. Note that the fields are private: this is because these store little endian scalars regardless of platform (since this is part of the serialized data). <code>EndianScalar</code> then converts back and forth, which is a no-op on all current mobile and desktop platforms, and a single machine instruction on the few remaining big endian platforms. </p><pre class="fragment">struct Monster : private flatbuffers::Table {
const Vec3 *pos() const { return GetStruct&lt;const Vec3 *&gt;(4); }
int16_t mana() const { return GetField&lt;int16_t&gt;(6, 150); }
int16_t hp() const { return GetField&lt;int16_t&gt;(8, 100); }
@@ -136,8 +130,7 @@ STRUCT_END(Vec3, 12);
const flatbuffers::Vector&lt;uint8_t&gt; *inventory() const { return GetPointer&lt;const flatbuffers::Vector&lt;uint8_t&gt; *&gt;(14); }
int8_t color() const { return GetField&lt;int8_t&gt;(16, 2); }
};
</pre><p>Tables are a bit more complicated. A table accessor struct is used to point at the serialized data for a table, which always starts with an offset to its vtable. It derives from <code>Table</code>, which contains the <code>GetField</code> helper functions. GetField takes a vtable offset, and a default value. It will look in the vtable at that offset. If the offset is out of bounds (data from an older version) or the vtable entry is 0, the field is not present and the default is returned. Otherwise, it uses the entry as an offset into the table to locate the field. </p>
<pre class="fragment">struct MonsterBuilder {
</pre><p>Tables are a bit more complicated. A table accessor struct is used to point at the serialized data for a table, which always starts with an offset to its vtable. It derives from <code>Table</code>, which contains the <code>GetField</code> helper functions. GetField takes a vtable offset, and a default value. It will look in the vtable at that offset. If the offset is out of bounds (data from an older version) or the vtable entry is 0, the field is not present and the default is returned. Otherwise, it uses the entry as an offset into the table to locate the field. </p><pre class="fragment">struct MonsterBuilder {
flatbuffers::FlatBufferBuilder &amp;fbb_;
flatbuffers::uoffset_t start_;
void add_pos(const Vec3 *pos) { fbb_.AddStruct(4, pos); }
@@ -149,8 +142,7 @@ STRUCT_END(Vec3, 12);
MonsterBuilder(flatbuffers::FlatBufferBuilder &amp;_fbb) : fbb_(_fbb) { start_ = fbb_.StartTable(); }
flatbuffers::Offset&lt;Monster&gt; Finish() { return flatbuffers::Offset&lt;Monster&gt;(fbb_.EndTable(start_, 7)); }
};
</pre><p><code>MonsterBuilder</code> is the base helper struct to construct a table using a <code>FlatBufferBuilder</code>. You can add the fields in any order, and the <code>Finish</code> call will ensure the correct vtable gets generated. </p>
<pre class="fragment">inline flatbuffers::Offset&lt;Monster&gt; CreateMonster(flatbuffers::FlatBufferBuilder &amp;_fbb, const Vec3 *pos, int16_t mana, int16_t hp, flatbuffers::Offset&lt;flatbuffers::String&gt; name, flatbuffers::Offset&lt;flatbuffers::Vector&lt;uint8_t&gt;&gt; inventory, int8_t color) {
</pre><p><code>MonsterBuilder</code> is the base helper struct to construct a table using a <code>FlatBufferBuilder</code>. You can add the fields in any order, and the <code>Finish</code> call will ensure the correct vtable gets generated. </p><pre class="fragment">inline flatbuffers::Offset&lt;Monster&gt; CreateMonster(flatbuffers::FlatBufferBuilder &amp;_fbb, const Vec3 *pos, int16_t mana, int16_t hp, flatbuffers::Offset&lt;flatbuffers::String&gt; name, flatbuffers::Offset&lt;flatbuffers::Vector&lt;uint8_t&gt;&gt; inventory, int8_t color) {
MonsterBuilder builder_(_fbb);
builder_.add_inventory(inventory);
builder_.add_name(name);
@@ -160,10 +152,8 @@ STRUCT_END(Vec3, 12);
builder_.add_color(color);
return builder_.Finish();
}
</pre><p><code>CreateMonster</code> is a convenience function that calls all functions in <code>MonsterBuilder</code> above for you. Note that if you pass values which are defaults as arguments, it will not actually construct that field, so you can probably use this function instead of the builder class in almost all cases. </p>
<pre class="fragment">inline const Monster *GetMonster(const void *buf) { return flatbuffers::GetRoot&lt;Monster&gt;(buf); }
</pre><p>This function is only generated for the root table type, to be able to start traversing a FlatBuffer from a raw buffer pointer. </p>
<pre class="fragment">}; // namespace MyGame
</pre><p><code>CreateMonster</code> is a convenience function that calls all functions in <code>MonsterBuilder</code> above for you. Note that if you pass values which are defaults as arguments, it will not actually construct that field, so you can probably use this function instead of the builder class in almost all cases. </p><pre class="fragment">inline const Monster *GetMonster(const void *buf) { return flatbuffers::GetRoot&lt;Monster&gt;(buf); }
</pre><p>This function is only generated for the root table type, to be able to start traversing a FlatBuffer from a raw buffer pointer. </p><pre class="fragment">}; // namespace MyGame
}; // namespace Sample</pre> </div></div><!-- contents -->
</div><!-- doc-content -->
<!-- Google Analytics -->