BigfootDev/flatbuffers
1
0
Fork 1
mirror of https://github.com/google/flatbuffers.git synced 2026-06-05 13:08:58 +00:00
Code Issues Packages Projects Releases Wiki Activity

Revamping the FlatBuffers docs.

Browse Source 
Adding an API reference for the supported languages.

General docs cleanup, including a new `tutorial` section that
supports all of the supported languages.

Added samples for each supported language to mirror the new
tutorial page.

Cleaned up all the links by making them `@ref` style links,
instead of referencing the names of the generated `.html` files.

Removed all generated files that were unnecessarily committed.

Also fixed the C# tests (two were failing due to a missing file).

Bug: b/25801305

Tested: Tested all samples on Ubuntu, Mac, and Android. Docs were
generated using doxygen and viewed on Chrome.

Change-Id: I2acaba6e332a15ae2deff5f26a4a25da7bd2c954
This commit is contained in:
Mark Klara
2015-12-03 20:30:54 -08:00
parent d75d29e2fe
commit 69a31b807a
115 changed files with 5537 additions and 5917 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
docs/source/Benchmarks.md
View File

@@ -1,4 +1,5 @@
# Benchmarks
Benchmarks {#flatbuffers_benchmarks}
==========
Comparing against other serialization solutions, running on Windows 7
64bit. We use the LITE runtime for Protocol Buffers (less code / lower
@@ -20,17 +21,17 @@ The benchmark object is a set of about 10 objects containing an array, 4
strings, and a large variety of int/float scalar values of all sizes,
meant to be representative of game data, e.g. a scene format.
| | FlatBuffers (binary) | Protocol Buffers LITE | Rapid JSON | FlatBuffers (JSON) | pugixml | Raw structs |
|--------------------------------------------------------|-----------------------|-----------------------|-----------------------|-----------------------| ----------------------| ----------------------|
| Decode + Traverse + Dealloc (1 million times, seconds) | 0.08 | 302 | 583 | 105 | 196 | 0.02 |
| Decode / Traverse / Dealloc (breakdown) | 0 / 0.08 / 0 | 220 / 0.15 / 81 | 294 / 0.9 / 287 | 70 / 0.08 / 35 | 41 / 3.9 / 150 | 0 / 0.02 / 0 |
| Encode (1 million times, seconds) | 3.2 | 185 | 650 | 169 | 273 | 0.15 |
| Wire format size (normal / zlib, bytes) | 344 / 220 | 228 / 174 | 1475 / 322 | 1029 / 298 | 1137 / 341 | 312 / 187 |
| Memory needed to store decoded wire (bytes / blocks) | 0 / 0 | 760 / 20 | 65689 / 4 | 328 / 1 | 34194 / 3 | 0 / 0 |
| Transient memory allocated during decode (KB) | 0 | 1 | 131 | 4 | 34 | 0 |
| Generated source code size (KB) | 4 | 61 | 0 | 4 | 0 | 0 |
| Field access in handwritten traversal code | typed accessors | typed accessors | manual error checking | typed accessors | manual error checking | typed but no safety |
| Library source code (KB) | 15 | some subset of 3800 | 87 | 43 | 327 | 0 |
| | FlatBuffers (binary) | Protocol Buffers LITE | Rapid JSON | FlatBuffers (JSON) | pugixml | Raw structs |
|--------------------------------------------------------|-----------------------|-----------------------|-----------------------|------------------------| ----------------------| ----------------------|
| Decode + Traverse + Dealloc (1 million times, seconds) | 0.08 | 302 | 583 | 105 | 196 | 0.02 |
| Decode / Traverse / Dealloc (breakdown) | 0 / 0.08 / 0 | 220 / 0.15 / 81 | 294 / 0.9 / 287 | 70 / 0.08 / 35 | 41 / 3.9 / 150 | 0 / 0.02 / 0 |
| Encode (1 million times, seconds) | 3.2 | 185 | 650 | 169 | 273 | 0.15 |
| Wire format size (normal / zlib, bytes) | 344 / 220 | 228 / 174 | 1475 / 322 | 1029 / 298 | 1137 / 341 | 312 / 187 |
| Memory needed to store decoded wire (bytes / blocks) | 0 / 0 | 760 / 20 | 65689 / 4 | 328 / 1 | 34194 / 3 | 0 / 0 |
| Transient memory allocated during decode (KB) | 0 | 1 | 131 | 4 | 34 | 0 |
| Generated source code size (KB) | 4 | 61 | 0 | 4 | 0 | 0 |
| Field access in handwritten traversal code | typed accessors | typed accessors | manual error checking | typed accessors | manual error checking | typed but no safety |
| Library source code (KB) | 15 | some subset of 3800 | 87 | 43 | 327 | 0 |
### Some other serialization systems we compared against but did not benchmark (yet), in rough order of applicability:
@@ -58,3 +59,5 @@ Code for these benchmarks sits in `benchmarks/` in git branch `benchmarks`.
It sits in its own branch because it has submodule dependencies that the main
project doesn't need, and the code standards do not meet those of the main
project. Please read `benchmarks/cpp/README.txt` before working with the code.
<br>

44
docs/source/Building.md
View File

@@ -1,8 +1,13 @@
# Building
Building {#flatbuffers_guide_building}
========
## Building with Visual Studio or Xcode projects
There are project files for Visual Studio and Xcode that should allow you
to build the compiler `flatc`, the samples and the tests out of the box.
## Building with CMake
Alternatively, the distribution comes with a `cmake` file that should allow
you to build project/make files for any platform. For details on `cmake`, see
<http://www.cmake.org>. In brief, depending on your platform, use one of
@@ -18,28 +23,45 @@ Note that to use clang instead of gcc, you may need to set up your environment
variables, e.g.
`CC=/usr/bin/clang CXX=/usr/bin/clang++ cmake -G "Unix Makefiles"`.
Optionally, run the `flattests` executable to ensure everything is working
correctly on your system. If this fails, please contact us!
Optionally, run the `flattests` executable from the root `flatbuffers/`
directory to ensure everything is working correctly on your system. If this
fails, please contact us!
Note that you MUST be in the root of the FlatBuffers distribution when you
run 'flattests' (and the samples), or it will fail to load its files.
Building should also produce two sample executables, `flatsamplebinary` and
`flatsampletext`, see the corresponding `.cpp` files in the
`flatbuffers/samples` directory.
Building should also produce two sample executables, `sample_binary` and
`sample_text`, see the corresponding `.cpp` file in the samples directory.
*Note that you MUST be in the root of the FlatBuffers distribution when you
run 'flattests' or `flatsampletext`, or it will fail to load its files.*
There is an `android` directory that contains all you need to build the test
executable on android (use the included `build_apk.sh` script, or use
## Building for Android
There is a `flatbuffers/android` directory that contains all you need to build
the test executable on android (use the included `build_apk.sh` script, or use
`ndk_build` / `adb` etc. as usual). Upon running, it will output to the log
if tests succeeded or not.
There is usually no runtime to compile, as the code consists of a single
header, `include/flatbuffers/flatbuffers.h`. You should add the
You may also run an android sample from inside the `flatbuffers/samples`, by
running the `android_sample.sh` script. Optionally, you may go to the
`flatbuffers/samples/android` folder and build the sample with the
`build_apk.sh` script or `ndk_build` / `adb` etc.
## Using FlatBuffers in your own projects.
For C++, there is usually no runtime to compile, as the code consists of a
single header, `include/flatbuffers/flatbuffers.h`. You should add the
`include` folder to your include paths. If you wish to be
able to load schemas and/or parse text into binary buffers at runtime,
you additionally need the other headers in `include/flatbuffers`. You must
also compile/link `src/idl_parser.cpp` (and `src/idl_gen_text.cpp` if you
also want to be able convert binary to text).
To see how to include FlatBuffers in any of our supported languages, please
view the [Tutorial](@ref flatbuffers_guide_tutorial) and select your appropriate
language using the radio buttons.
#### For Google Play apps
For applications on Google Play that integrate this library, usage is tracked.
This tracking is done automatically using the embedded version string
(flatbuffer_version_string), and helps us continue to optimize it.

1
docs/source/CONTRIBUTING.md Symbolic link
View File

@@ -0,0 +1 @@
../../CONTRIBUTING

3
docs/source/Compiler.md
View File

@@ -1,4 +1,5 @@
# Using the schema compiler
Using the schema compiler {#flatbuffers_guide_using_schema_compiler}
=========================
Usage:

292
docs/source/CppUsage.md
View File

@@ -1,227 +1,100 @@
# Use in C++
Use in C++ {#flatbuffers_guide_use_cpp}
==========
Assuming you have written a schema using the above language in say
`mygame.fbs` (FlatBuffer Schema, though the extension doesn't matter),
you've generated a C++ header called `mygame_generated.h` using the
## Before you get started
Before diving into the FlatBuffers usage in C++, it should be noted that
the [Tutorial](@ref flatbuffers_guide_tutorial) page has a complete guide
to general FlatBuffers usage in all of the supported languages (including C++).
This page is designed to cover the nuances of FlatBuffers usage, specific to
C++.
#### Prerequisites
This page assumes you have written a FlatBuffers schema and compiled it
with the Schema Compiler. If you have not, please see
[Using the schema compiler](@ref flatbuffers_guide_using_schema_compiler)
and [Writing a schema](@ref flatbuffers_guide_writing_schema).
Assuming you wrote a schema, say `mygame.fbs` (though the extension doesn't
matter), you've generated a C++ header called `mygame_generated.h` using the
compiler (e.g. `flatc -c mygame.fbs`), you can now start using this in
your program by including the header. As noted, this header relies on
`flatbuffers/flatbuffers.h`, which should be in your include path.
### Writing in C++
## FlatBuffers C++ library code location
To start creating a buffer, create an instance of `FlatBufferBuilder`
which will contain the buffer as it grows:
The code for the FlatBuffers C++ library can be found at
`flatbuffers/include/flatbuffers`. You can browse the library code on the
[FlatBuffers GitHub page](https://github.com/google/flatbuffers/tree/master/
include/flatbuffers).
## Testing the FlatBuffers C++ library
The code to test the C++ library can be found at `flatbuffers/tests`.
The test code itself is located in
[test.cpp](https://github.com/google/flatbuffers/blob/master/tests/test.cpp).
This test file is built alongside `flatc`. To review how to build the project,
please read the [Building](@ref flatbuffers_guide_building) documenation.
To run the tests, execute `flattests` from the root `flatbuffers/` directory.
For example, on [Linux](https://en.wikipedia.org/wiki/Linux), you would simply
run: `./flattests`.
## Using the FlatBuffers C++ library
*Note: See [Tutorial](@ref flatbuffers_guide_tutorial) for a more in-depth
example of how to use FlatBuffers in C++.*
FlatBuffers supports both reading and writing FlatBuffers in C++.
To use FlatBuffers in your code, first generate the C++ classes from your
schema with the `--cpp` option to `flatc`. Then you can include both FlatBuffers
and the generated code to read or write FlatBuffers.
For example, here is how you would read a FlatBuffer binary file in C++:
First, include the library and generated code. Then read the file into
a `char *` array, which you pass to `GetMonster()`.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
FlatBufferBuilder fbb;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include "flatbuffers/flatbuffers.h"
#include "monster_test_generate.h"
#include <cstdio> // For printing and file access.
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:
FILE* file = fopen("monsterdata_test.mon", "rb");
fseek(file, 0L, SEEK_END);
int length = ftell(file);
fseek(file, 0L, SEEK_SET);
char *data = new char[length];
fread(data, sizeof(char), length, file);
fclose(file);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
auto name = fbb.CreateString("MyMonster");
unsigned char inv[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
auto inventory = fbb.CreateVector(inv, 10);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
`CreateString` and `CreateVector` serialize these two built-in
datatypes, and return offsets into the serialized data indicating where
they are stored, such that `Monster` below can refer to them.
`CreateString` can also take an `std::string`, or a `const char *` with
an explicit length, and is suitable for holding UTF-8 and binary
data if needed.
`CreateVector` can also take an `std::vector`. 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 `CreateVectorOfStructs`
instead.
To create a vector of nested objects (e.g. tables, strings or other vectors)
collect their offsets in a temporary array/vector, then call `CreateVector`
on that (see e.g. the array of strings example in `test.cpp`
`CreateFlatBufferTest`).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
Vec3 vec(1, 2, 3);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
`Vec3` 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.
We have now serialized the non-scalar components of of the monster
example, so we could create the monster something like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
auto mloc = CreateMonster(fbb, &vec, 150, 80, name, inventory, Color_Red, 0, Any_NONE);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note that we're passing `150` for the `mana` 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.
We do something similarly for the union field `test` by specifying a `0` offset
and the `NONE` enum value (part of every union) to indicate we don't actually
want to write this field. You can use `0` also as a default for other
non-scalar types, such as strings, vectors and tables. To pass an actual
table, pass a preconstructed table as `mytable.Union()` that corresponds to
union enum you're passing.
Tables (like `Monster`) give you full flexibility on what fields you write
(unlike `Vec3`, which always has all fields set because it is a `struct`).
If you want even more control over this (i.e. skip fields even when they are
not default), instead of the convenient `CreateMonster` call we can also
build the object field-by-field manually:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
MonsterBuilder mb(fbb);
mb.add_pos(&vec);
mb.add_hp(80);
mb.add_name(name);
mb.add_inventory(inventory);
auto mloc = mb.Finish();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We start with a temporary helper class `MonsterBuilder` (which is
defined in our generated code also), then call the various `add_`
methods to set fields, and `Finish` to complete the object. This is
pretty much the same code as you find inside `CreateMonster`, 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).
Regardless of whether you used `CreateMonster` or `MonsterBuilder`, you
now have an offset to the root of your data, and you can finish the
buffer using:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
FinishMonsterBuffer(fbb, mloc);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 `fbb.GetBufferPointer()`, and it's size from
`fbb.GetSize()`.
Calling code may take ownership of the buffer with `fbb.ReleaseBufferPointer()`.
Should you do it, the `FlatBufferBuilder` will be in an invalid state,
and *must* be cleared before it can be used again.
However, it also means you are able to destroy the builder while keeping
the buffer in your application.
`samples/sample_binary.cpp` is a complete code sample similar to
the code above, that also includes the reading code below.
### Reading in C++
If you've received a buffer from somewhere (disk, network, etc.) you can
directly start traversing it using:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
auto monster = GetMonster(buffer_pointer);
auto monster = GetMonster(data);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
`monster` is of type `Monster *`, and points to somewhere *inside* your
buffer (root object pointers are not the same as `buffer_pointer` !).
If you look in your generated header, you'll see it has
convenient accessors for all fields, e.g.
convenient accessors for all fields, e.g. `hp()`, `mana()`, etc:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
assert(monster->hp() == 80);
assert(monster->mana() == 150); // default
assert(strcmp(monster->name()->c_str(), "MyMonster") == 0);
printf("%d\n", monster->hp()); // `80`
printf("%d\n", monster->mana()); // default value of `150`
printf("%s\n", monster->name()->c_str()); // "MyMonster"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
These should all be true. Note that we never stored a `mana` value, so
it will return the default.
*Note: That we never stored a `mana` value, so it will return the default.*
To access sub-objects, in this case the `Vec3`:
## Reflection (& Resizing)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
auto pos = monster->pos();
assert(pos);
assert(pos->z() == 3);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is experimental support for reflection in FlatBuffers, allowing you to
read and write data even if you don't know the exact format of a buffer, and
even allows you to change sizes of strings and vectors in-place.
If we had not set the `pos` field during serialization, it would be
`NULL`.
Similarly, we can access elements of the inventory array:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
auto inv = monster->inventory();
assert(inv);
assert(inv->Get(9) == 9);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
### Mutating FlatBuffers
As you saw above, typically once you have created a FlatBuffer, it is
read-only from that moment on. There are however cases where you have just
received a FlatBuffer, and you'd like to modify something about it before
sending it on to another recipient. With the above functionality, you'd have
to generate an entirely new FlatBuffer, while tracking what you modify in your
own data structures. This is inconvenient.
For this reason FlatBuffers can also be mutated in-place. While this is great
for making small fixes to an existing buffer, you generally want to create
buffers from scratch whenever possible, since it is much more efficient and
the API is much more general purpose.
To get non-const accessors, invoke `flatc` with `--gen-mutable`.
Similar to the reading API above, you now can:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
auto monster = GetMutableMonster(buffer_pointer); // non-const
monster->mutate_hp(10); // Set table field.
monster->mutable_pos()->mutate_z(4); // Set struct field.
monster->mutable_inventory()->Mutate(0, 1); // Set vector element.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We use the somewhat verbose term `mutate` instead of `set` to indicate that
this is a special use case, not to be confused with the default way of
constructing FlatBuffer data.
After the above mutations, you can send on the FlatBuffer to a new recipient
without any further work!
Note that any `mutate_` functions on tables return a bool, which is false
if the field we're trying to set isn't present in the buffer. Fields are not
present if they weren't set, or even if they happen to be equal to the
default value. For example, in the creation code above we set the `mana` field
to `150`, which is the default value, so it was never stored in the buffer.
Trying to call mutate_mana() on such data will return false, and the value won't
actually be modified!
One way to solve this is to call `ForceDefaults()` on a
`FlatBufferBuilder` to force all fields you set to actually be written. This
of course increases the size of the buffer somewhat, but this may be
acceptable for a mutable buffer.
Alternatively, you can use the more powerful reflection functionality:
### Reflection (& Resizing)
If the above ways of accessing a buffer are still too static for you, there is
experimental support for reflection in FlatBuffers, allowing you to read and
write data even if you don't know the exact format of a buffer, and even allows
you to change sizes of strings and vectors in-place.
The way this works is very elegant, there is actually a FlatBuffer schema that
The way this works is very elegant; there is actually a FlatBuffer schema that
describes schemas (!) which you can find in `reflection/reflection.fbs`.
The compiler `flatc` can write out any schemas it has just parsed as a binary
The compiler, `flatc`, can write out any schemas it has just parsed as a binary
FlatBuffer, corresponding to this meta-schema.
Loading in one of these binary schemas at runtime allows you traverse any
@@ -232,9 +105,10 @@ For convenient field manipulation, you can include the header
`flatbuffers/reflection.h` which includes both the generated code from the meta
schema, as well as a lot of helper functions.
And example of usage for the moment you can find in `test.cpp/ReflectionTest()`.
And example of usage, for the time being, can be found in
`test.cpp/ReflectionTest()`.
### Storing maps / dictionaries in a FlatBuffer
## Storing maps / dictionaries in a FlatBuffer
FlatBuffers doesn't support maps natively, but there is support to
emulate their behavior with vectors and binary search, which means you
@@ -260,7 +134,7 @@ To use it:
only works if the vector has been sorted, it will likely not find elements
if it hasn't been sorted.
### Direct memory access
## Direct memory access
As you can see from the above examples, all elements in a buffer are
accessed through generated accessors. This is because everything is
@@ -285,7 +159,7 @@ machines, so only use tricks like this if you can guarantee you're not
shipping on a big endian machine (an `assert(FLATBUFFERS_LITTLEENDIAN)`
would be wise).
### Access of untrusted buffers
## Access of untrusted buffers
The generated accessor functions access fields over offsets, which is
very quick. These offsets are not verified at run-time, so a malformed
@@ -342,7 +216,7 @@ accepted).
There are two ways to use text formats:
### Using the compiler as a conversion tool
#### Using the compiler as a conversion tool
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
@@ -354,7 +228,7 @@ users/developers to perform, though you might be able to automate it.
This will generate the binary file `mydata_wire.bin` which can be loaded
as before.
### Making your program capable of loading text directly
#### Making your program capable of loading text directly
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
@@ -400,7 +274,7 @@ file, that you can access as described above.
`samples/sample_text.cpp` is a code sample showing the above operations.
### Threading
## Threading
Reading a FlatBuffer does not touch any memory outside the original buffer,
and is entirely read-only (all const), so is safe to access from multiple
@@ -413,3 +287,5 @@ share instances of FlatBufferBuilder between threads (recommended), or
manually wrap it in synchronisation primites. There's no automatic way to
accomplish this, by design, as we feel multithreaded construction
of a single buffer will be rare, and synchronisation overhead would be costly.
<br>

48
docs/source/FlatBuffers.md
View File

@@ -1,9 +1,12 @@
# FlatBuffers
FlatBuffers {#flatbuffers_index}
===========
FlatBuffers is an efficient cross platform serialization library for C++, Java,
C#, Go, Python and JavaScript (C, PHP & Ruby in progress).
It was originally created at Google for game development and other
performance-critical applications.
# Overview {#flatbuffers_overview}
[FlatBuffers](@ref flatbuffers_overview) is an efficient cross platform
serialization library for C++, C#, Go, Java, JavaScript, PHP, and Python
(C and Ruby in progress). It was originally created at Google for game
development and other performance-critical applications.
It is available as Open Source on [GitHub](http://github.com/google/flatbuffers)
under the Apache license, v2 (see LICENSE.txt).
@@ -26,7 +29,7 @@ under the Apache license, v2 (see LICENSE.txt).
projects where spending time and space (many memory allocations) to
be able to access or construct serialized data is undesirable, such
as in games or any other performance sensitive applications. See the
[benchmarks](md__benchmarks.html) for details.
[benchmarks](@ref flatbuffers_benchmarks) for details.
- **Flexible** - Optional fields means not only do you get great
forwards and backwards compatibility (increasingly important for
@@ -76,7 +79,7 @@ In this context, it is only a better choice for systems that have very
little to no information ahead of time about what data needs to be stored.
Read more about the "why" of FlatBuffers in the
[white paper](md__white_paper.html).
[white paper](@ref flatbuffers_white_paper).
### Who uses FlatBuffers?
- [Cocos2d-x](http://www.cocos2d-x.org/), the #1 open source mobile game
@@ -118,22 +121,23 @@ sections provide a more in-depth usage guide.
## In-depth documentation
- How to [build the compiler](md__building.html) and samples on various
platforms.
- How to [use the compiler](md__compiler.html).
- How to [write a schema](md__schemas.html).
- How to [use the generated C++ code](md__cpp_usage.html) in your own
programs.
- How to [use the generated Java/C# code](md__java_usage.html) in your own
programs.
- How to [use the generated Go code](md__go_usage.html) in your own
programs.
- [Support matrix](md__support.html) for platforms/languages/features.
- Some [benchmarks](md__benchmarks.html) showing the advantage of using
- How to [build the compiler](@ref flatbuffers_guide_building) and samples on
various platforms.
- How to [use the compiler](@ref flatbuffers_guide_using_schema_compiler).
- How to [write a schema](@ref flatbuffers_guide_writing_schema).
- How to [use the generated C++ code](@ref flatbuffers_guide_use_cpp) in your
own programs.
- How to [use the generated Java/C# code](@ref flatbuffers_guide_use_java_c-sharp)
in your own programs.
- How to [use the generated Go code](@ref flatbuffers_guide_use_go) in your
own programs.
- [Support matrix](@ref flatbuffers_support) for platforms/languages/features.
- Some [benchmarks](@ref flatbuffers_benchmarks) showing the advantage of
using FlatBuffers.
- A [white paper](@ref flatbuffers_white_paper) explaining the "why" of
FlatBuffers.
- A [white paper](md__white_paper.html) explaining the "why" of FlatBuffers.
- A description of the [internals](md__internals.html) of FlatBuffers.
- A formal [grammar](md__grammar.html) of the schema language.
- A description of the [internals](@ref flatbuffers_internals) of FlatBuffers.
- A formal [grammar](@ref flatbuffers_grammar) of the schema language.
## Online resources

26
docs/source/GoApi.md Normal file
View File

@@ -0,0 +1,26 @@
Go API
======
\addtogroup flatbuffers_go_api
<!-- Note: The `GoApi_generate.txt` code snippet was generated using `godoc` and
customized for use with this markdown file. To regenerate the file, use the
`godoc` tool (http://godoc.org) with the files in the `flatbuffers/go`
folder.
You may need to ensure that copies of the files exist in the `src/`
subfolder at the path set by the `$GOROOT` environment variable. You can
either move the files to `$GOROOT/src/flatbuffers` manually, if `$GOROOT`
is already set, otherwise you will need to manually set the `$GOROOT`
variable to a path and create `src/flatbuffers` subfolders at that path.
Then copy the flatbuffers files into `$GOROOT/src/flatbuffers`. (Some
versions of `godoc` include a `-path` flag. This could be used instead, if
available).
Once the files exist at the `$GOROOT/src/flatbuffers` location, you can
regenerate this doc using the following command:
`godoc flatbuffers > GoApi_generated.txt`.
After the documentation is generated, you will have to manually remove any
non-user facing documentation from this file. -->
\snippet GoApi_generated.txt Go API

125
docs/source/GoApi_generated.txt Normal file
View File

@@ -0,0 +1,125 @@
// This file was generated using `godoc` and customized for use with the
// API Reference documentation. To recreate this file, use the `godoc` tool
// (http://godoc.org) with the files in the `flatbuffers/go` folder.
//
// Note: You may need to ensure that copies of the files exist in the
// `src/` subfolder at the path set by the `$GOROOT` environment variable.
// You can either move the files to `$GOROOT/src/flatbuffers` manually, if
// `$GOROOT` is already set, otherwise you will need to manually set the
// `$GOROOT` variable to a path and create `src/flatbuffers` subfolders at that
// path. Then copy these files into `$GOROOT/src/flatbuffers`. (Some versions of
// `godoc` include a `-path` flag. This could be used instead, if available).
//
// Once the files exist at the `$GOROOT/src/flatbuffers` location, you can
// regenerate this doc using the following command:
// `godoc flatbuffers > GoApi_generated.txt`.
//
// After the documentation is generated, you will have to manually remove any
// non-user facing documentation from this file.
/// [Go API]
PACKAGE DOCUMENTATION
package flatbuffers
Package flatbuffers provides facilities to read and write flatbuffers
objects.
TYPES
type Builder struct {
// `Bytes` gives raw access to the buffer. Most users will want to use
// FinishedBytes() instead.
Bytes []byte
}
Builder is a state machine for creating FlatBuffer objects. Use a
Builder to construct object(s) starting from leaf nodes.
A Builder constructs byte buffers in a last-first manner for simplicity
and performance.
FUNCTIONS
func NewBuilder(initialSize int) *Builder
NewBuilder initializes a Builder of size `initial_size`. The internal
buffer is grown as needed.
func (b *Builder) CreateByteString(s []byte) UOffsetT
CreateByteString writes a byte slice as a string (null-terminated).
func (b *Builder) CreateByteVector(v []byte) UOffsetT
CreateByteVector writes a ubyte vector
func (b *Builder) CreateString(s string) UOffsetT
CreateString writes a null-terminated string as a vector.
func (b *Builder) EndVector(vectorNumElems int) UOffsetT
EndVector writes data necessary to finish vector construction.
func (b *Builder) Finish(rootTable UOffsetT)
Finish finalizes a buffer, pointing to the given `rootTable`.
func (b *Builder) FinishedBytes() []byte
FinishedBytes returns a pointer to the written data in the byte buffer.
Panics if the builder is not in a finished state (which is caused by
calling `Finish()`).
func (b *Builder) Head() UOffsetT
Head gives the start of useful data in the underlying byte buffer. Note:
unlike other functions, this value is interpreted as from the left.
func (b *Builder) PrependBool(x bool)
PrependBool prepends a bool to the Builder buffer. Aligns and checks for
space.
func (b *Builder) PrependByte(x byte)
PrependByte prepends a byte to the Builder buffer. Aligns and checks for
space.
func (b *Builder) PrependFloat32(x float32)
PrependFloat32 prepends a float32 to the Builder buffer. Aligns and
checks for space.
func (b *Builder) PrependFloat64(x float64)
PrependFloat64 prepends a float64 to the Builder buffer. Aligns and
checks for space.
func (b *Builder) PrependInt16(x int16)
PrependInt16 prepends a int16 to the Builder buffer. Aligns and checks
for space.
func (b *Builder) PrependInt32(x int32)
PrependInt32 prepends a int32 to the Builder buffer. Aligns and checks
for space.
func (b *Builder) PrependInt64(x int64)
PrependInt64 prepends a int64 to the Builder buffer. Aligns and checks
for space.
func (b *Builder) PrependInt8(x int8)
PrependInt8 prepends a int8 to the Builder buffer. Aligns and checks for
space.
func (b *Builder) PrependUOffsetT(off UOffsetT)
PrependUOffsetT prepends an UOffsetT, relative to where it will be
written.
func (b *Builder) PrependUint16(x uint16)
PrependUint16 prepends a uint16 to the Builder buffer. Aligns and checks
for space.
func (b *Builder) PrependUint32(x uint32)
PrependUint32 prepends a uint32 to the Builder buffer. Aligns and checks
for space.
func (b *Builder) PrependUint64(x uint64)
PrependUint64 prepends a uint64 to the Builder buffer. Aligns and checks
for space.
func (b *Builder) PrependUint8(x uint8)
PrependUint8 prepends a uint8 to the Builder buffer. Aligns and checks
for space.
func (b *Builder) Reset()
Reset truncates the underlying Builder buffer, facilitating alloc-free
reuse of a Builder. It also resets bookkeeping data.
/// [Go API]

142
docs/source/GoUsage.md
View File

@@ -1,11 +1,51 @@
# Use in Go
Use in Go {#flatbuffers_guide_use_go}
=========
There's experimental support for reading FlatBuffers in Go. Generate code
for Go with the `-g` option to `flatc`.
## Before you get started
See `go_test.go` for an example. You import the generated code, read a
FlatBuffer binary file into a `[]byte`, which you pass to the
`GetRootAsMonster` function:
Before diving into the FlatBuffers usage in Go, it should be noted that
the [Tutorial](@ref flatbuffers_guide_tutorial) page has a complete guide
to general FlatBuffers usage in all of the supported languages (including Go).
This page is designed to cover the nuances of FlatBuffers usage, specific to
Go.
You should also have read the [Building](@ref flatbuffers_guide_building)
documentation to build `flatc` and should be familiar with
[Using the schema compiler](@ref flatbuffers_guide_using_schema_compiler) and
[Writing a schema](@ref flatbuffers_guide_writing_schema).
## FlatBuffers Go library code location
The code for the FlatBuffers Go library can be found at
`flatbuffers/go`. You can browse the library code on the [FlatBuffers
GitHub page](https://github.com/google/flatbuffers/tree/master/go).
## Testing the FlatBuffers Go library
The code to test the Go library can be found at `flatbuffers/tests`.
The test code itself is located in [go_test.go](https://github.com/google/
flatbuffers/blob/master/tests/go_test.go).
To run the tests, use the [GoTest.sh](https://github.com/google/flatbuffers/
blob/master/tests/GoTest.sh) shell script.
*Note: The shell script requires [Go](https://golang.org/doc/install) to
be installed.*
## Using the FlatBuffers Go library
*Note: See [Tutorial](@ref flatbuffers_guide_tutorial) for a more in-depth
example of how to use FlatBuffers in Go.*
FlatBuffers supports reading and writing binary FlatBuffers in Go.
To use FlatBuffers in your own code, first generate Go classes from your
schema with the `--go` option to `flatc`. Then you can include both FlatBuffers
and the generated code to read or write a FlatBuffer.
For example, here is how you would read a FlatBuffer binary file in Go: First,
include the library and generated code. Then read a FlatBuffer binary file into
a `[]byte`, which you pass to the `GetRootAsMonster` function:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.go}
import (
@@ -27,96 +67,10 @@ Now you can access values like this:
pos := monster.Pos(nil)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note that whenever you access a new object like in the `Pos` example above,
a new temporary accessor object gets created. If your code is very performance
sensitive (you iterate through a lot of objects), you can replace nil with a
pointer to a `Vec3` object you've already created. This allows
you to reuse it across many calls and reduce the amount of object allocation
(and thus garbage collection) your program does.
To access vectors you pass an extra index to the
vector field accessor. Then a second method with the same name suffixed
by `Length` let's you know the number of elements you can access:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.go}
for i := 0; i < monster.InventoryLength(); i++ {
monster.Inventory(i) // do something here
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can also construct these buffers in Go using the functions found in the
generated code, and the FlatBufferBuilder class:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.go}
builder := flatbuffers.NewBuilder(0)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create strings:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.go}
str := builder.CreateString("MyMonster")
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create a table with a struct contained therein:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.go}
example.MonsterStart(builder)
example.MonsterAddPos(builder, example.CreateVec3(builder, 1.0, 2.0, 3.0, 3.0, 4, 5, 6))
example.MonsterAddHp(builder, 80)
example.MonsterAddName(builder, str)
example.MonsterAddInventory(builder, inv)
example.MonsterAddTest_Type(builder, 1)
example.MonsterAddTest(builder, mon2)
example.MonsterAddTest4(builder, test4s)
mon := example.MonsterEnd(builder)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unlike C++, Go does not support table creation functions like 'createMonster()'.
This is to create the buffer without
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
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.
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
will be `a`, `c` and `d`.
Vectors also use this start/end pattern to allow vectors of both scalar types
and structs:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.go}
example.MonsterStartInventoryVector(builder, 5)
for i := 4; i >= 0; i-- {
builder.PrependByte(byte(i))
}
inv := builder.EndVector(5)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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. Use the correct `Prepend` call for the type,
or `PrependUOffsetT` for offsets. 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
`PrependUOffset` for any previously constructed objects (such as other tables,
strings, vectors). For structs, you use the appropriate `create` function
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
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.
<br>

3
docs/source/Grammar.md
View File

@@ -1,4 +1,5 @@
# Grammar of the schema language
Grammar of the schema language {#flatbuffers_grammar}
==============================
schema = include*
( namespace\_decl | type\_decl | enum\_decl | root\_decl |

14
docs/source/Internals.md
View File

@@ -1,4 +1,5 @@
# FlatBuffer Internals
FlatBuffer Internals {#flatbuffers_internals}
====================
This section is entirely optional for the use of FlatBuffers. In normal
usage, you should never need the information contained herein. If you're
@@ -16,7 +17,7 @@ byte-swap intrinsics.
On purpose, the format leaves a lot of details about where exactly
things live in memory undefined, e.g. fields in a table can have any
order, and objects to some extend can be stored in many orders. This is
order, and objects to some extent can be stored in many orders. This is
because the format doesn't need this information to be efficient, and it
leaves room for optimization and extension (for example, fields can be
packed in a way that is most compact). Instead, the format is defined in
@@ -228,7 +229,12 @@ Otherwise, it uses the entry as an offset into the table to locate the field.
`FlatBufferBuilder`. You can add the fields in any order, and the `Finish`
call will ensure the correct vtable gets generated.
inline flatbuffers::Offset<Monster> CreateMonster(flatbuffers::FlatBufferBuilder &_fbb, const Vec3 *pos, int16_t mana, int16_t hp, flatbuffers::Offset<flatbuffers::String> name, flatbuffers::Offset<flatbuffers::Vector<uint8_t>> inventory, int8_t color) {
inline flatbuffers::Offset<Monster> CreateMonster(flatbuffers::FlatBufferBuilder &_fbb,
const Vec3 *pos, int16_t mana,
int16_t hp,
flatbuffers::Offset<flatbuffers::String> name,
flatbuffers::Offset<flatbuffers::Vector<uint8_t>> inventory,
int8_t color) {
MonsterBuilder builder_(_fbb);
builder_.add_inventory(inventory);
builder_.add_name(name);
@@ -285,3 +291,5 @@ Note that this not the only possible encoding, since the writer has some
flexibility in which of the children of root object to write first (though in
this case there's only one string), and what order to write the fields in.
Different orders may also cause different alignments to happen.
<br>

141
docs/source/JavaCsharpUsage.md Executable file
View File

@@ -0,0 +1,141 @@
Use in Java/C# {#flatbuffers_guide_use_java_c-sharp}
==============
## Before you get started
Before diving into the FlatBuffers usage in Java or C#, it should be noted that
the [Tutorial](@ref flatbuffers_guide_tutorial) page has a complete guide to
general FlatBuffers usage in all of the supported languages (including both Java
and C#). This page is designed to cover the nuances of FlatBuffers usage,
specific to Java and C#.
You should also have read the [Building](@ref flatbuffers_guide_building)
documentation to build `flatc` and should be familiar with
[Using the schema compiler](@ref flatbuffers_guide_using_schema_compiler) and
[Writing a schema](@ref flatbuffers_guide_writing_schema).
## FlatBuffers Java and C-sharp code location
#### Java
The code for the FlatBuffers Java library can be found at
`flatbuffers/java/com/google/flatbuffers`. You can browse the library on the
[FlatBuffers GitHub page](https://github.com/google/flatbuffers/tree/master/
java/com/google/flatbuffers).
#### C-sharp
The code for the FlatBuffers C# library can be found at
`flatbuffers/net/FlatBuffers`. You can browse the library on the
[FlatBuffers GitHub page](https://github.com/google/flatbuffers/tree/master/net/
FlatBuffers).
## Testing the FlatBuffers Java and C-sharp libraries
The code to test the libraries can be found at `flatbuffers/tests`.
#### Java
The test code for Java is located in [JavaTest.java](https://github.com/google
/flatbuffers/blob/master/tests/JavaTest.java).
To run the tests, use either [JavaTest.sh](https://github.com/google/
flatbuffers/blob/master/tests/JavaTest.sh) or [JavaTest.bat](https://github.com/
google/flatbuffers/blob/master/tests/JavaTest.bat), depending on your operating
system.
*Note: These scripts require that [Java](https://www.oracle.com/java/index.html)
is installed.*
#### C-sharp
The test code for C# is located in the [FlatBuffers.Test](https://github.com/
google/flatbuffers/tree/master/tests/FlatBuffers.Test) subfolder. To run the
tests, open `FlatBuffers.Test.csproj` in [Visual Studio](
https://www.visualstudio.com), and compile/run the project.
Optionally, you can run this using [Mono](http://www.mono-project.com/) instead.
Once you have installed `Mono`, you can run the tests from the command line
by running the following commands from inside the `FlatBuffers.Test` folder:
~~~{.sh}
mcs *.cs ../MyGame/Example/*.cs ../../net/FlatBuffers/*.cs
mono Assert.exe
~~~
## Using the FlatBuffers Java (and C#) library
*Note: See [Tutorial](@ref flatbuffers_guide_tutorial) for a more in-depth
example of how to use FlatBuffers in Java or C#.*
FlatBuffers supports reading and writing binary FlatBuffers in Java and C#.
To use FlatBuffers in your own code, first generate Java classes from your
schema with the `--java` option to `flatc`. (Or for C# with `--csharp`).
Then you can include both FlatBuffers and the generated code to read
or write a FlatBuffer.
For example, here is how you would read a FlatBuffer binary file in Java:
First, import the library and generated code. Then, you read a FlatBuffer binary
file into a `byte[]`. You then turn the `byte[]` into a `ByteBuffer`, which you
pass to the `getRootAsMyRootType` function:
*Note: The code here is written from the perspective of Java. Code for both
languages is both generated and used in nearly the exact same way, with only
minor differences. These differences are
[explained in a section below](#differences_in_c-sharp).*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
import MyGame.Example.*;
import com.google.flatbuffers.FlatBufferBuilder;
// This snippet ignores exceptions for brevity.
File file = new File("monsterdata_test.mon");
RandomAccessFile f = new RandomAccessFile(file, "r");
byte[] data = new byte[(int)f.length()];
f.readFully(data);
f.close();
ByteBuffer bb = ByteBuffer.wrap(data);
Monster monster = Monster.getRootAsMonster(bb);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now you can access the data from the `Monster monster`:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
short hp = monster.hp();
Vec3 pos = monster.pos();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<a name="differences_in_c-sharp">
#### Differences in C-sharp
</a>
C# code works almost identically to Java, with only a few minor differences.
You can see an example of C# code in
`tests/FlatBuffers.Test/FlatBuffersExampleTests.cs` or
`samples/SampleBinary.cs`.
First of all, naming follows standard C# style with `PascalCasing` identifiers,
e.g. `GetRootAsMyRootType`. Also, values (except vectors and unions) are
available as properties instead of parameterless accessor methods as in Java.
The performance-enhancing methods to which you can pass an already created
object are prefixed with `Get`, e.g.:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cs}
// property
var pos = monster.Pos;
// method filling a preconstructed object
var preconstructedPos = new Vec3();
monster.GetPos(preconstructedPos);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## Text parsing
There currently is no support for parsing text (Schema's and JSON) directly
from Java or C#, though you could use the C++ parser through native call
interfaces available to each language. Please see the
C++ documentation for more on text parsing.
<br>

105
docs/source/JavaScriptUsage.md Executable file
View File

@@ -0,0 +1,105 @@
Use in JavaScript {#flatbuffers_guide_use_javascript}
=================
## Before you get started
Before diving into the FlatBuffers usage in JavaScript, it should be noted that
the [Tutorial](@ref flatbuffers_guide_tutorial) page has a complete guide to
general FlatBuffers usage in all of the supported languages
(including JavaScript). This page is specifically designed to cover the nuances
of FlatBuffers usage in JavaScript.
You should also have read the [Building](@ref flatbuffers_guide_building)
documentation to build `flatc` and should be familiar with
[Using the schema compiler](@ref flatbuffers_guide_using_schema_compiler) and
[Writing a schema](@ref flatbuffers_guide_writing_schema).
## FlatBuffers JavaScript library code location
The code for the FlatBuffers JavaScript library can be found at
`flatbuffers/js`. You can browse the library code on the [FlatBuffers
GitHub page](https://github.com/google/flatbuffers/tree/master/js).
## Testing the FlatBuffers JavaScript library
The code to test the JavaScript library can be found at `flatbuffers/tests`.
The test code itself is located in [JavaScriptTest.js](https://github.com/
google/flatbuffers/blob/master/tests/JavaScriptTest.js).
To run the tests, use the [JavaScriptTest.sh](https://github.com/google/
flatbuffers/blob/master/tests/JavaScriptTest.sh) shell script.
*Note: The JavaScript test file requires [Node.js](https://nodejs.org/en/).*
## Using the FlatBuffers JavaScript libary
*Note: See [Tutorial](@ref flatbuffers_guide_tutorial) for a more in-depth
example of how to use FlatBuffers in JavaScript.*
FlatBuffers supports both reading and writing FlatBuffers in JavaScript.
To use FlatBuffers in your own code, first generate JavaScript classes from your
schema with the `--js` option to `flatc`. Then you can include both FlatBuffers
and the generated code to read or write a FlatBuffer.
For example, here is how you would read a FlatBuffer binary file in Javascript:
First, include the library and generated code. Then read the file into an
`Uint8Array`. Make a `flatbuffers.ByteBuffer` out of the `Uint8Array`, and pass
the ByteBuffer to the `getRootAsMonster` function.
*Note: Both JavaScript module loaders (e.g. Node.js) and browser-based
HTML/JavaScript code segments are shown below in the following snippet:*
~~~{.js}
// Note: These require functions are specific to JavaScript module loaders
// (namely, Node.js). See below for a browser-based example.
var fs = require('fs');
var flatbuffers = require('../flatbuffers').flatbuffers;
var MyGame = require('./monster_generated').MyGame;
var data = new Uint8Array(fs.readFileSync('monster.dat'));
var buf = new flatbuffers.ByteBuffer(data);
var monster = MyGame.Example.Monster.getRootAsMonster(buf);
//--------------------------------------------------------------------------//
// Note: This code is specific to browser-based HTML/JavaScript. See above
// for the code using JavaScript module loaders (e.g. Node.js).
<script src="../js/flatbuffers.js"></script>
<script src="monster_generated.js"></script>
<script>
function readFile() {
var reader = new FileReader(); // This example uses the HTML5 FileReader.
var file = document.getElementById(
'file_input').files[0]; // "monster.dat" from the HTML <input> field.
reader.onload = function() { // Executes after the file is read.
var data = new Uint8Array(reader.result);
var buf = new flatbuffers.ByteBuffer(data);
var monster = MyGame.Example.Monster.getRootAsMonster(buf);
}
reader.readAsArrayBuffer(file);
}
</script>
// Open the HTML file in a browser and select "monster.dat" from with the
// <input> field.
<input type="file" id="file_input" onchange="readFile();">
~~~
Now you can access values like this:
~~~{.js}
var hp = monster.hp();
var pos = monster.pos();
~~~
## Text parsing FlatBuffers in JavaScript
There currently is no support for parsing text (Schema's and JSON) directly
from JavaScript.

224
docs/source/JavaUsage.md
View File

@@ -1,224 +0,0 @@
# Use in Java/C-sharp
FlatBuffers supports reading and writing binary FlatBuffers in Java and C#.
Generate code for Java with the `-j` option to `flatc`, or for C# with `-n`
(think .Net).
Note that this document is from the perspective of Java. Code for both languages
is generated in the same way, with only minor differences. These differences
are [explained in a section below](#differences-in-c-sharp).
See `javaTest.java` for an example. Essentially, you read a FlatBuffer binary
file into a `byte[]`, which you then turn into a `ByteBuffer`, which you pass to
the `getRootAsMyRootType` function:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
ByteBuffer bb = ByteBuffer.wrap(data);
Monster monster = Monster.getRootAsMonster(bb);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Now you can access values much like C++:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
short hp = monster.hp();
Vec3 pos = monster.pos();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note that whenever you access a new object like in the `pos` example above,
a new temporary accessor object gets created. If your code is very performance
sensitive (you iterate through a lot of objects), there's a second `pos()`
method to which you can pass a `Vec3` object you've already created. This allows
you to reuse it across many calls and reduce the amount of object allocation
(and thus garbage collection) your program does.
Java does not support unsigned scalars. This means that any unsigned types you
use in your schema will actually be represented as a signed value. This means
all bits are still present, but may represent a negative value when used.
For example, to read a `byte b` as an unsigned number, you can do:
`(short)(b & 0xFF)`
The default string accessor (e.g. `monster.name()`) currently always create
a new Java `String` when accessed, since FlatBuffer's UTF-8 strings can't be
used in-place by `String`. Alternatively, use `monster.nameAsByteBuffer()`
which returns a `ByteBuffer` referring to the UTF-8 data in the original
`ByteBuffer`, which is much more efficient. The `ByteBuffer`'s `position`
points to the first character, and its `limit` to just after the last.
Vector access is also a bit different from C++: you pass an extra index
to the vector field accessor. Then a second method with the same name
suffixed by `Length` let's you know the number of elements you can access:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
for (int i = 0; i < monster.inventoryLength(); i++)
monster.inventory(i); // do something here
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Alternatively, much like strings, you can use `monster.inventoryAsByteBuffer()`
to get a `ByteBuffer` referring to the whole vector. Use `ByteBuffer` methods
like `asFloatBuffer` to get specific views if needed.
If you specified a file_indentifier in the schema, you can query if the
buffer is of the desired type before accessing it using:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
if (Monster.MonsterBufferHasIdentifier(bb)) ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## Buffer construction in Java
You can also construct these buffers in Java using the static methods found
in the generated code, and the FlatBufferBuilder class:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
FlatBufferBuilder fbb = new FlatBufferBuilder();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create strings:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
int str = fbb.createString("MyMonster");
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create a table with a struct contained therein:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
Monster.startMonster(fbb);
Monster.addPos(fbb, Vec3.createVec3(fbb, 1.0f, 2.0f, 3.0f, 3.0, (byte)4, (short)5, (byte)6));
Monster.addHp(fbb, (short)80);
Monster.addName(fbb, str);
Monster.addInventory(fbb, inv);
Monster.addTest_type(fbb, (byte)1);
Monster.addTest(fbb, mon2);
Monster.addTest4(fbb, test4s);
int mon = Monster.endMonster(fbb);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For some simpler types, you can use a convenient `create` function call that
allows you to construct tables in one function call. This example definition
however contains an inline struct field, so we have to create the table
manually.
This is to create the buffer without using temporary object allocation.
It's important to understand that fields that are structs are inline (like
`Vec3` above), and MUST thus be created between the start and end calls of
a table. Everything else (other tables, strings, vectors) MUST be created
before the start of the table they are referenced in.
Structs do have convenient methods that even have arguments for nested structs.
As you can see, references to other objects (e.g. the string above) are simple
ints, and thus do not have the type-safety of the Offset type in C++. Extra
care must thus be taken that you set the right offset on the right field.
Vectors can be created from the corresponding Java array like so:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
int inv = Monster.createInventoryVector(fbb, new byte[] { 0, 1, 2, 3, 4 });
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This works for arrays of scalars and (int) offsets to strings/tables,
but not structs. If you want to write structs, or what you want to write
does not sit in an array, you can also use the start/end pattern:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
Monster.startInventoryVector(fbb, 5);
for (byte i = 4; i >=0; i--) fbb.addByte(i);
int inv = fbb.endVector();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can use the generated method `startInventoryVector` to conveniently call
`startVector` 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 `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
any previously constructed objects (such as other tables, strings, vectors).
For structs, you use the appropriate `create` function in-line, as shown
above in the `Monster` example.
To finish the buffer, call:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
Monster.finishMonsterBuffer(fbb, mon);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The buffer is now ready to be transmitted. It is contained in the `ByteBuffer`
which you can obtain from `fbb.dataBuffer()`. Importantly, the valid data does
not start from offset 0 in this buffer, but from `fbb.dataBuffer().position()`
(this is because the data was built backwards in memory).
It ends at `fbb.capacity()`.
## Differences in C-sharp
C# code works almost identically to Java, with only a few minor differences.
You can see an example of C# code in `tests/FlatBuffers.Test/FlatBuffersExampleTests.cs`.
First of all, naming follows standard C# style with `PascalCasing` identifiers,
e.g. `GetRootAsMyRootType`. Also, values (except vectors and unions) are available
as properties instead of parameterless accessor methods as in Java. The
performance-enhancing methods to which you can pass an already created object
are prefixed with `Get`, e.g.:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cs}
// property
var pos = monster.Pos;
// method filling a preconstructed object
var preconstructedPos = new Vec3();
monster.GetPos(preconstructedPos);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## Text parsing
There currently is no support for parsing text (Schema's and JSON) directly
from Java or C#, though you could use the C++ parser through native call
interfaces available to each language. Please see the
C++ documentation for more on text parsing.
### Mutating FlatBuffers
As you saw above, typically once you have created a FlatBuffer, it is
read-only from that moment on. There are however cases where you have just
received a FlatBuffer, and you'd like to modify something about it before
sending it on to another recipient. With the above functionality, you'd have
to generate an entirely new FlatBuffer, while tracking what you modify in your
own data structures. This is inconvenient.
For this reason FlatBuffers can also be mutated in-place. While this is great
for making small fixes to an existing buffer, you generally want to create
buffers from scratch whenever possible, since it is much more efficient and
the API is much more general purpose.
To get non-const accessors, invoke `flatc` with `--gen-mutable`.
You now can:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.java}
Monster monster = Monster.getRootAsMonster(bb);
monster.mutateHp(10); // Set table field.
monster.pos().mutateZ(4); // Set struct field.
monster.mutateInventory(0, 1); // Set vector element.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We use the somewhat verbose term `mutate` instead of `set` to indicate that
this is a special use case, not to be confused with the default way of
constructing FlatBuffer data.
After the above mutations, you can send on the FlatBuffer to a new recipient
without any further work!
Note that any `mutate` functions on tables return a boolean, which is false
if the field we're trying to set isn't present in the buffer. Fields are not
present if they weren't set, or even if they happen to be equal to the
default value. For example, in the creation code above we set the `mana` field
to `150`, which is the default value, so it was never stored in the buffer.
Trying to call mutateMana() on such data will return false, and the value won't
actually be modified!
One way to solve this is to call `forceDefaults()` on a
`FlatBufferBuilder` to force all fields you set to actually be written. This
of course increases the size of the buffer somewhat, but this may be
acceptable for a mutable buffer.

89
docs/source/PHPUsage.md Normal file
View File

@@ -0,0 +1,89 @@
Use in PHP {#flatbuffers_guide_use_php}
==========
## Before you get started
Before diving into the FlatBuffers usage in PHP, it should be noted that
the [Tutorial](@ref flatbuffers_guide_tutorial) page has a complete guide to
general FlatBuffers usage in all of the supported languages
(including PHP). This page is specifically designed to cover the nuances of
FlatBuffers usage in PHP.
You should also have read the [Building](@ref flatbuffers_guide_building)
documentation to build `flatc` and should be familiar with
[Using the schema compiler](@ref flatbuffers_guide_using_schema_compiler) and
[Writing a schema](@ref flatbuffers_guide_writing_schema).
## FlatBuffers PHP library code location
The code for FlatBuffers PHP library can be found at `flatbuffers/php`. You
can browse the library code on the [FlatBuffers
GitHub page](https://github.com/google/flatbuffers/tree/master/php).
## Testing the FlatBuffers JavaScript library
The code to test the PHP library can be found at `flatbuffers/tests`.
The test code itself is located in [phpTest.php](https://github.com/google/
flatbuffers/blob/master/tests/phpTest.php).
You can run the test with `php phpTest.php` from the command line.
*Note: The PHP test file requires
[PHP](http://php.net/manual/en/install.php) to be installed.*
## Using theFlatBuffers PHP library
*Note: See [Tutorial](@ref flatbuffers_guide_tutorial) for a more in-depth
example of how to use FlatBuffers in PHP.*
FlatBuffers supports both reading and writing FlatBuffers in PHP.
To use FlatBuffers in your own code, first generate PHP classes from your schema
with the `--php` option to `flatc`. Then you can include both FlatBuffers and
the generated code to read or write a FlatBuffer.
For example, here is how you would read a FlatBuffer binary file in PHP:
First, include the library and generated code (using the PSR `autoload`
function). Then you can read a FlatBuffer binary file, which you
pass the contents of to the `GetRootAsMonster` function:
~~~{.php}
// It is recommended that your use PSR autoload when using FlatBuffers in PHP.
// Here is an example:
function __autoload($class_name) {
// The last segment of the class name matches the file name.
$class = substr($class_name, strrpos($class_name, "\\") + 1);
$root_dir = join(DIRECTORY_SEPARATOR, array(dirname(dirname(__FILE__)))); // `flatbuffers` root.
// Contains the `*.php` files for the FlatBuffers library and the `flatc` generated files.
$paths = array(join(DIRECTORY_SEPARATOR, array($root_dir, "php")),
join(DIRECTORY_SEPARATOR, array($root_dir, "tests", "MyGame", "Example")));
foreach ($paths as $path) {
$file = join(DIRECTORY_SEPARATOR, array($path, $class . ".php"));
if (file_exists($file)) {
require($file);
break;
}
}
// Read the contents of the FlatBuffer binary file.
$filename = "monster.dat";
$handle = fopen($filename, "rb");
$contents = $fread($handle, filesize($filename));
fclose($handle);
// Pass the contents to `GetRootAsMonster`.
$monster = \MyGame\Example\Monster::GetRootAsMonster($contents);
~~~
Now you can access values like this:
~~~{.php}
$hp = $monster->GetHp();
$pos = $monster->GetPos();
~~~
## Text Parsing
There currently is no support for parsing text (Schema's and JSON) directly
from PHP.

138
docs/source/PythonUsage.md
View File

@@ -1,11 +1,52 @@
# Use in Python
Use in Python {#flatbuffers_guide_use_python}
=============
There's experimental support for reading FlatBuffers in Python. Generate
code for Python with the `-p` option to `flatc`.
## Before you get started
See `py_test.py` for an example. You import the generated code, read a
FlatBuffer binary file into a `bytearray`, which you pass to the
`GetRootAsMonster` function:
Before diving into the FlatBuffers usage in Python, it should be noted that the
[Tutorial](@ref flatbuffers_guide_tutorial) page has a complete guide to general
FlatBuffers usage in all of the supported languages (including Python). This
page is designed to cover the nuances of FlatBuffers usage, specific to
Python.
You should also have read the [Building](@ref flatbuffers_guide_building)
documentation to build `flatc` and should be familiar with
[Using the schema compiler](@ref flatbuffers_guide_using_schema_compiler) and
[Writing a schema](@ref flatbuffers_guide_writing_schema).
## FlatBuffers Python library code location
The code for the FlatBuffers Python library can be found at
`flatbuffers/python/flatbuffers`. You can browse the library code on the
[FlatBuffers GitHub page](https://github.com/google/flatbuffers/tree/master/
python).
## Testing the FlatBuffers Python library
The code to test the Python library can be found at `flatbuffers/tests`.
The test code itself is located in [py_test.py](https://github.com/google/
flatbuffers/blob/master/tests/py_test.py).
To run the tests, use the [PythonTest.sh](https://github.com/google/flatbuffers/
blob/master/tests/PythonTest.sh) shell script.
*Note: This script requires [python](https://www.python.org/) to be
installed.*
## Using the FlatBuffers Python library
*Note: See [Tutorial](@ref flatbuffers_guide_tutorial) for a more in-depth
example of how to use FlatBuffers in Python.*
There is support for both reading and writing FlatBuffers in Python.
To use FlatBuffers in your own code, first generate Python classes from your
schema with the `--python` option to `flatc`. Then you can include both
FlatBuffers and the generated code to read or write a FlatBuffer.
For example, here is how you would read a FlatBuffer binary file in Python:
First, import the library and the generated code. Then read a FlatBuffer binary
file into a `bytearray`, which you pass to the `GetRootAsMonster` function:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.py}
import MyGame.Example as example
@@ -23,93 +64,10 @@ Now you can access values like this:
pos = monster.Pos()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To access vectors you pass an extra index to the
vector field accessor. Then a second method with the same name suffixed
by `Length` let's you know the number of elements you can access:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.py}
for i in xrange(monster.InventoryLength()):
monster.Inventory(i) # do something here
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can also construct these buffers in Python using the functions found
in the generated code, and the FlatBufferBuilder class:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.py}
builder = flatbuffers.Builder(0)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create strings:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.py}
s = builder.CreateString("MyMonster")
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create a table with a struct contained therein:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.py}
example.MonsterStart(builder)
example.MonsterAddPos(builder, example.CreateVec3(builder, 1.0, 2.0, 3.0, 3.0, 4, 5, 6))
example.MonsterAddHp(builder, 80)
example.MonsterAddName(builder, str)
example.MonsterAddInventory(builder, inv)
example.MonsterAddTest_Type(builder, 1)
example.MonsterAddTest(builder, mon2)
example.MonsterAddTest4(builder, test4s)
mon = example.MonsterEnd(builder)
final_flatbuffer = builder.Output()
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unlike C++, Python does not support table creation functions like 'createMonster()'.
This is to create the buffer without
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
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.
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
will be `a`, `c` and `d`.
Vectors also use this start/end pattern to allow vectors of both scalar types
and structs:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.py}
example.MonsterStartInventoryVector(builder, 5)
i = 4
while i >= 0:
builder.PrependByte(byte(i))
i -= 1
inv = builder.EndVector(5)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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. Use the correct `Prepend` call for the type,
or `PrependUOffsetT` for offsets. 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
`PrependUOffset` for any previously constructed objects (such as other tables,
strings, vectors). For structs, you use the appropriate `create` function
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
There currently is no support for parsing text (Schema's and JSON) directly
from Python, though you could use the C++ parser through SWIG or ctypes. Please
see the C++ documentation for more on text parsing.
<br>

32
docs/source/README_TO_GENERATE_DOCS.md Normal file
View File

@@ -0,0 +1,32 @@
## Prerequisites
To generate the docs for FlatBuffers from the source files, you
will first need to install two programs.
1. You will need to install `doxygen`. See
[Download Doxygen](http://www.stack.nl/~dimitri/doxygen/download.html).
2. You will need to install `doxypypy` to format python comments appropriately.
Install it from [here](https://github.com/Feneric/doxypypy).
*Note: You will need both `doxygen` and `doxypypy` to be in your
[PATH](https://en.wikipedia.org/wiki/PATH_(variable)) environment variable.*
After you have both of those files installed and in your path, you need to
set up the `py_filter` to invoke `doxypypy` from `doxygen`.
Follow the steps
[here](https://github.com/Feneric/doxypypy#invoking-doxypypy-from-doxygen).
## Generating Docs
Run the following commands to generate the docs:
`cd flatbuffers/docs/source`
`doxygen`
The output is placed in `flatbuffers/docs/html`.
*Note: The Go API Reference code must be generated ahead of time. For
instructions on how to regenerated this file, please read the comments
in `GoApi.md`.*

41
docs/source/Schemas.md
View File

@@ -1,7 +1,8 @@
# Writing a schema
Writing a schema {#flatbuffers_guide_writing_schema}
================
The syntax of the schema language (aka IDL, Interface Definition
Language) should look quite familiar to users of any of the C family of
The syntax of the schema language (aka IDL, [Interface Definition Language][])
should look quite familiar to users of any of the C family of
languages, and also to users of other IDLs. Let's look at an example
first:
@@ -34,14 +35,14 @@ first:
root_type Monster;
(Weapon & Pickup not defined as part of this example).
(`Weapon` & `Pickup` not defined as part of this example).
### Tables
Tables are the main way of defining objects in FlatBuffers, and consist
of a name (here `Monster`) and a list of fields. Each field has a name,
a type, and optionally a default value (if omitted, it defaults to 0 /
NULL).
a type, and optionally a default value (if omitted, it defaults to `0` /
`NULL`).
Each field is optional: It does not have to appear in the wire
representation, and you can choose to omit fields for each individual
@@ -85,13 +86,13 @@ parent object, and use no virtual table).
Built-in scalar types are:
- 8 bit: `byte ubyte bool`
- 8 bit: `byte`, `ubyte`, `bool`
- 16 bit: `short ushort`
- 16 bit: `short`, `ushort`
- 32 bit: `int uint float`
- 32 bit: `int`, `uint`, `float`
- 64 bit: `long ulong double`
- 64 bit: `long`, `ulong`, `double`
Built-in non-scalar types:
@@ -111,18 +112,19 @@ high bit yet.
### (Default) Values
Values are a sequence of digits, optionally followed by a `.` and more digits
for float constants, and optionally prefixed by a `-`. Floats may end with an
`e` or `E`, followed by a `+` or `-` and more digits (scientific notation).
Values are a sequence of digits. Values may be optionally followed by a decimal
point (`.`) and more digits, for float constants, or optionally prefixed by
a `-`. Floats may also be in scientific notation; optionally ending with an `e`
or `E`, followed by a `+` or `-` and more digits.
Only scalar values can have defaults, non-scalar (string/vector/table) fields
default to NULL when not present.
default to `NULL` when not present.
You generally do not want to change default values after they're initially
defined. Fields that have the default value are not actually stored in the
serialized data but are generated in code, so when you change the default, you'd
now get a different value than from code generated from an older version of
the schema. There are situations however where this may be
the schema. There are situations, however, where this may be
desirable, especially if you can ensure a simultaneous rebuild of
all code.
@@ -142,7 +144,7 @@ itself, by handling unknown enum values.
Unions share a lot of properties with enums, but instead of new names
for constants, you use names of tables. You can then declare
a union field which can hold a reference to any of those types, and
a union field, which can hold a reference to any of those types, and
additionally a hidden field with the suffix `_type` is generated that
holds the corresponding enum value, allowing you to know which type to
cast to at runtime.
@@ -178,7 +180,7 @@ included files (those you still generate separately).
### Root type
This declares what you consider to be the root table (or struct) of the
serialized data. This is particular important for parsing JSON data,
serialized data. This is particularly important for parsing JSON data,
which doesn't include object type information.
### File identification and extension
@@ -234,7 +236,7 @@ in the corresponding C++ code. Multiple such lines per item are allowed.
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 `deprecated` are understood by the compiler,
not. Some attributes like `deprecated` are understood by the compiler;
user defined ones need to be declared with the attribute declaration
(like `priority` in the example above), and are
available to query if you parse the schema at runtime.
@@ -421,3 +423,6 @@ Occasionally ok. You've renamed fields, which will break all code (and JSON
files!) that use this schema, but as long as the change is obvious, this is not
incompatible with the actual binary buffers, since those only ever address
fields by id/offset.
<br>
[Interface Definition Language]: https://en.wikipedia.org/wiki/Interface_description_language

5
docs/source/Support.md
View File

@@ -1,4 +1,5 @@
# Platform / Language / Feature support
Platform / Language / Feature support {#flatbuffers_support}
=====================================
FlatBuffers is actively being worked on, which means that certain platform /
language / feature combinations may not be available yet.
@@ -39,3 +40,5 @@ Primary authors (github) | gwvo | gwvo | ev*/js*| rw | rw | ev
* js = jonsimantov
* mik = mikkelfj
* ch = chobie
<br>

1723
docs/source/Tutorial.md Normal file
View File

File diff suppressed because it is too large Load Diff

5
docs/source/WhitePaper.md
View File

@@ -1,4 +1,5 @@
# FlatBuffers white paper
FlatBuffers white paper {#flatbuffers_white_paper}
=======================
This document tries to shed some light on to the "why" of FlatBuffers, a
new serialization library.
@@ -124,4 +125,4 @@ offered by .proto files in the following ways:
- A parser that can deal with both schemas and data definitions (JSON
compatible) uniformly.
<br>

108
docs/source/doxyfile
View File

@@ -88,7 +88,7 @@ OUTPUT_LANGUAGE = English
# documentation (similar to Javadoc). Set to NO to disable this.
# The default value is: YES.
BRIEF_MEMBER_DESC = NO
BRIEF_MEMBER_DESC = YES
# If the REPEAT_BRIEF tag is set to YES doxygen will prepend the brief
# description of a member or function before the detailed description
@@ -97,7 +97,7 @@ BRIEF_MEMBER_DESC = NO
# brief descriptions will be completely suppressed.
# The default value is: YES.
REPEAT_BRIEF = NO
REPEAT_BRIEF = YES
# This tag implements a quasi-intelligent brief description abbreviator that is
# used to form the text in various listings. Each string in this list, if found
@@ -177,7 +177,7 @@ SHORT_NAMES = NO
# description.)
# The default value is: NO.
JAVADOC_AUTOBRIEF = NO
JAVADOC_AUTOBRIEF = YES
# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first
# line (until the first dot) of a Qt-style comment as the brief description. If
@@ -203,7 +203,7 @@ MULTILINE_CPP_IS_BRIEF = NO
# documentation from any documented member that it re-implements.
# The default value is: YES.
INHERIT_DOCS = NO
INHERIT_DOCS = YES
# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce a
# new page for each member. If set to NO, the documentation of a member will be
@@ -216,7 +216,7 @@ SEPARATE_MEMBER_PAGES = NO
# uses this value to replace tabs by spaces in code fragments.
# Minimum value: 1, maximum value: 16, default value: 4.
TAB_SIZE = 1
TAB_SIZE = 2
# This tag can be used to specify a number of aliases that act as commands in
# the documentation. An alias has the form:
@@ -296,7 +296,9 @@ MARKDOWN_SUPPORT = YES
# or globally by setting AUTOLINK_SUPPORT to NO.
# The default value is: YES.
AUTOLINK_SUPPORT = YES
AUTOLINK_SUPPORT = NO # Due to the multiple languages included in the API
# reference for FlatBuffers, the Auto-links were
# wrong more often than not.
# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
# to include (a tag file for) the STL sources as input, then you should set this
@@ -347,7 +349,7 @@ DISTRIBUTE_GROUP_DOC = NO
# \nosubgrouping command.
# The default value is: YES.
SUBGROUPING = NO
SUBGROUPING = YES
# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions
# are shown inside the group in which they are included (e.g. using \ingroup)
@@ -424,7 +426,7 @@ EXTRACT_PACKAGE = NO
# included in the documentation.
# The default value is: NO.
EXTRACT_STATIC = NO
EXTRACT_STATIC = YES
# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) defined
# locally in source files will be included in the documentation. If set to NO
@@ -508,7 +510,7 @@ HIDE_SCOPE_NAMES = NO
# the files that are included by a file in the documentation of that file.
# The default value is: YES.
SHOW_INCLUDE_FILES = NO
SHOW_INCLUDE_FILES = YES
# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
# files with double quotes in the documentation rather than with sharp brackets.
@@ -520,21 +522,21 @@ FORCE_LOCAL_INCLUDES = NO
# documentation for inline members.
# The default value is: YES.
INLINE_INFO = NO
INLINE_INFO = YES
# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the
# (detailed) documentation of file and class members alphabetically by member
# name. If set to NO the members will appear in declaration order.
# The default value is: YES.
SORT_MEMBER_DOCS = NO
SORT_MEMBER_DOCS = YES
# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief
# descriptions of file, namespace and class members alphabetically by member
# name. If set to NO the members will appear in declaration order.
# The default value is: NO.
SORT_BRIEF_DOCS = NO
SORT_BRIEF_DOCS = YES
# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the
# (brief and detailed) documentation of class members so that constructors and
@@ -600,7 +602,7 @@ GENERATE_BUGLIST = NO
# the documentation.
# The default value is: YES.
GENERATE_DEPRECATEDLIST= NO
GENERATE_DEPRECATEDLIST= YES
# The ENABLED_SECTIONS tag can be used to enable conditional documentation
# sections, marked by \if <section_label> ... \endif and \cond <section_label>
@@ -624,21 +626,21 @@ MAX_INITIALIZER_LINES = 30
# will mention the files that were used to generate the documentation.
# The default value is: YES.
SHOW_USED_FILES = NO
SHOW_USED_FILES = YES
# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This
# will remove the Files entry from the Quick Index and from the Folder Tree View
# (if specified).
# The default value is: YES.
SHOW_FILES = NO
SHOW_FILES = YES
# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
# page. This will remove the Namespaces entry from the Quick Index and from the
# Folder Tree View (if specified).
# The default value is: YES.
SHOW_NAMESPACES = NO
SHOW_NAMESPACES = YES
# The FILE_VERSION_FILTER tag can be used to specify a program or script that
# doxygen should invoke to get the current version for each file (typically from
@@ -661,7 +663,7 @@ FILE_VERSION_FILTER =
# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
# tag is left empty.
LAYOUT_FILE =
LAYOUT_FILE = doxygen_layout.xml
# The CITE_BIB_FILES tag can be used to specify one or more bib files containing
# the reference definitions. This must be a list of .bib files. The .bib
@@ -692,14 +694,14 @@ QUIET = NO
# Tip: Turn warnings on while writing the documentation.
# The default value is: YES.
WARNINGS = NO
WARNINGS = YES
# If the WARN_IF_UNDOCUMENTED tag is set to YES, then doxygen will generate
# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag
# will automatically be disabled.
# The default value is: YES.
WARN_IF_UNDOCUMENTED = NO
WARN_IF_UNDOCUMENTED = YES
# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
# potential errors in the documentation, such as not documenting some parameters
@@ -749,13 +751,26 @@ INPUT = "FlatBuffers.md" \
"Schemas.md" \
"CppUsage.md" \
"GoUsage.md" \
"JavaUsage.md" \
"JavaCsharpUsage.md" \
"JavaScriptUsage.md" \
"PHPUsage.md" \
"PythonUsage.md" \
"Support.md" \
"Benchmarks.md" \
"WhitePaper.md" \
"Internals.md" \
"Grammar.md"
"Grammar.md" \
"CONTRIBUTING.md" \
"Tutorial.md" \
"GoApi.md" \
"groups" \
"../../java/com/google/flatbuffers" \
"../../python/flatbuffers/builder.py" \
"../../js/flatbuffers.js" \
"../../php/FlatbufferBuilder.php" \
"../../net/FlatBuffers/FlatBufferBuilder.cs" \
"../../include/flatbuffers/flatbuffers.h" \
"../../go/builder.go"
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
@@ -816,13 +831,14 @@ FILE_PATTERNS = *.c \
*.ucf \
*.qsf \
*.as \
*.js
*.js \
*.go
# The RECURSIVE tag can be used to specify whether or not subdirectories should
# be searched for input files as well.
# The default value is: NO.
RECURSIVE = NO
RECURSIVE = YES
# The EXCLUDE tag can be used to specify files and/or directories that should be
# excluded from the INPUT source files. This way you can easily exclude a
@@ -847,7 +863,8 @@ EXCLUDE_SYMLINKS = NO
# Note that the wildcards are matched against the file with absolute path, so to
# exclude all test directories for example use the pattern */test/*
EXCLUDE_PATTERNS =
EXCLUDE_PATTERNS = *_test.py |
__init__.py
# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
# (namespaces, classes, functions, etc.) that should be excluded from the
@@ -864,7 +881,7 @@ EXCLUDE_SYMBOLS =
# that contain example code fragments that are included (see the \include
# command).
EXAMPLE_PATH =
EXAMPLE_PATH = "GoApi_generated.txt"
# If the value of the EXAMPLE_PATH tag contains directories, you can use the
# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and
@@ -910,7 +927,7 @@ INPUT_FILTER =
# filters are used. If the FILTER_PATTERNS tag is empty or if none of the
# patterns match the file name, INPUT_FILTER is applied.
FILTER_PATTERNS =
FILTER_PATTERNS = *.py=py_filter
# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
# INPUT_FILTER ) will also be used to filter the input files that are used for
@@ -978,7 +995,7 @@ REFERENCES_RELATION = NO
# link to the documentation.
# The default value is: YES.
REFERENCES_LINK_SOURCE = NO
REFERENCES_LINK_SOURCE = YES
# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
# source code will show a tooltip with additional information such as prototype,
@@ -1018,26 +1035,7 @@ USE_HTAGS = NO
# See also: Section \class.
# The default value is: YES.
VERBATIM_HEADERS = NO
# If the CLANG_ASSISTED_PARSING tag is set to YES, then doxygen will use the
# clang parser (see: http://clang.llvm.org/) for more acurate parsing at the
# cost of reduced performance. This can be particularly helpful with template
# rich C++ code for which doxygen's built-in parser lacks the necessary type
# information.
# Note: The availability of this option depends on whether or not doxygen was
# compiled with the --with-libclang option.
# The default value is: NO.
CLANG_ASSISTED_PARSING = NO
# If clang assisted parsing is enabled you can provide the compiler with command
# line options that you would normally use when invoking the compiler. Note that
# the include paths will already be set by doxygen for the files and directories
# specified with INPUT and INCLUDE_PATH.
# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
CLANG_OPTIONS =
VERBATIM_HEADERS = YES
#---------------------------------------------------------------------------
# Configuration options related to the alphabetical class index
@@ -1048,7 +1046,7 @@ CLANG_OPTIONS =
# classes, structs, unions or interfaces.
# The default value is: YES.
ALPHABETICAL_INDEX = NO
ALPHABETICAL_INDEX = YES
# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
# which the alphabetical index list will be split.
@@ -1129,7 +1127,7 @@ HTML_FOOTER = ../footer.html
# obsolete.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_STYLESHEET = style.css
HTML_STYLESHEET =
# The HTML_EXTRA_STYLESHEET tag can be used to specify an additional user-
# defined cascading style sheet that is included after the standard style sheets
@@ -1140,7 +1138,7 @@ HTML_STYLESHEET = style.css
# see the documentation.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_EXTRA_STYLESHEET =
HTML_EXTRA_STYLESHEET = style.css
# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
# other source files which should be copied to the HTML output directory. Note
@@ -1150,7 +1148,9 @@ HTML_EXTRA_STYLESHEET =
# files will be copied as-is; there are no commands or markers available.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_EXTRA_FILES = ../images/fpl_logo_small.png ../images/ftv2mnode.png ../images/ftv2pnode.png
HTML_EXTRA_FILES = "../images/fpl_logo_small.png" \
"../images/ftv2mnode.png" \
"../images/ftv2pnode.png"
# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
# will adjust the colors in the stylesheet and background images according to
@@ -1407,7 +1407,7 @@ ECLIPSE_DOC_ID = org.doxygen.Project
# The default value is: NO.
# This tag requires that the tag GENERATE_HTML is set to YES.
DISABLE_INDEX = YES
DISABLE_INDEX = NO
# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
# structure should be generated to display hierarchical information. If the tag
@@ -1538,7 +1538,7 @@ MATHJAX_CODEFILE =
# The default value is: YES.
# This tag requires that the tag GENERATE_HTML is set to YES.
SEARCHENGINE = NO
SEARCHENGINE = YES
# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
# implemented using a web server instead of a web client using Javascript. There
@@ -2071,7 +2071,7 @@ EXTERNAL_GROUPS = NO
# be listed.
# The default value is: YES.
EXTERNAL_PAGES = NO
EXTERNAL_PAGES = YES
# The PERL_PATH should be the absolute path and name of the perl script
# interpreter (i.e. the result of 'which perl').

230
docs/source/doxygen_layout.xml Normal file
View File

@@ -0,0 +1,230 @@
<!-- Copyright 2015 Google Inc. All rights reserved.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<doxygenlayout version="1.0">
<navindex>
<tab type="mainpage" visible="no" title=""/>
<tab type="usergroup" url="" title="Programmer's Guide">
<tab type="user" url="@ref flatbuffers_guide_building"
title="Building"/>
<tab type="user" url="@ref flatbuffers_guide_tutorial" title="Tutorial"/>
<tab type="user" url="@ref flatbuffers_guide_using_schema_compiler"
title="Using the schema compiler"/>
<tab type="user" url="@ref flatbuffers_guide_writing_schema"
title="Writing a schema"/>
<tab type="user" url="@ref flatbuffers_guide_use_cpp"
title="Use in C++"/>
<tab type="user" url="@ref flatbuffers_guide_use_go"
title="Use in Go"/>
<tab type="user" url="@ref flatbuffers_guide_use_java_c-sharp"
title="Use in Java/C#"/>
<tab type="user" url="@ref flatbuffers_guide_use_javascript"
title="Use in JavaScript"/>
<tab type="user" url="@ref flatbuffers_guide_use_php"
title="Use in PHP"/>
<tab type="user" url="@ref flatbuffers_guide_use_python"
title="Use in Python"/>
</tab>
<tab type="user" url="@ref flatbuffers_support"
title="Platform / Language / Feature support"/>
<tab type="user" url="@ref flatbuffers_benchmarks"
title="Benchmarks"/>
<tab type="user" url="@ref flatbuffers_white_paper"
title="FlatBuffers white paper"/>
<tab type="user" url="@ref flatbuffers_internals"
title="FlatBuffers internals"/>
<tab type="user" url="@ref flatbuffers_grammar"
title="Grammar of the schema langauge"/>
<tab type="usergroup" url="" title="API Reference">
<tab type="modules" visible="yes" title="APIs" intro=""/>
<tab type="classes" visible="yes" title="">
<tab type="classlist" visible="yes" title="" intro=""/>
<tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/>
<tab type="hierarchy" visible="yes" title="" intro=""/>
<tab type="classmembers" visible="yes" title="" intro=""/>
</tab>
</tab>
<tab type="user" url="@ref contributing" title="Contributing"/>
</navindex>
<!-- Layout definition for a class page -->
<class>
<briefdescription visible="yes"/>
<includes visible="$SHOW_INCLUDE_FILES"/>
<inheritancegraph visible="$CLASS_GRAPH"/>
<collaborationgraph visible="$COLLABORATION_GRAPH"/>
<detaileddescription title=""/>
<memberdecl>
<nestedclasses visible="yes" title=""/>
<publictypes title=""/>
<services title=""/>
<interfaces title=""/>
<publicslots title=""/>
<signals title=""/>
<publicmethods title=""/>
<publicstaticmethods title=""/>
<publicattributes title=""/>
<publicstaticattributes title=""/>
<protectedtypes title=""/>
<protectedslots title=""/>
<protectedmethods title=""/>
<protectedstaticmethods title=""/>
<protectedattributes title=""/>
<protectedstaticattributes title=""/>
<packagetypes title=""/>
<packagemethods title=""/>
<packagestaticmethods title=""/>
<packageattributes title=""/>
<packagestaticattributes title=""/>
<properties title=""/>
<events title=""/>
<privatetypes title=""/>
<privateslots title=""/>
<privatemethods title=""/>
<privatestaticmethods title=""/>
<privateattributes title=""/>
<privatestaticattributes title=""/>
<friends title=""/>
<related title="" subtitle=""/>
<membergroups visible="yes"/>
</memberdecl>
<memberdef>
<inlineclasses title=""/>
<typedefs title=""/>
<enums title=""/>
<services title=""/>
<interfaces title=""/>
<constructors title=""/>
<functions title=""/>
<related title=""/>
<variables title=""/>
<properties title=""/>
<events title=""/>
</memberdef>
<allmemberslink visible="yes"/>
<usedfiles visible="$SHOW_USED_FILES"/>
<authorsection visible="yes"/>
</class>
<!-- Layout definition for a namespace page -->
<namespace>
<briefdescription visible="yes"/>
<memberdecl>
<nestednamespaces visible="yes" title=""/>
<constantgroups visible="yes" title=""/>
<classes visible="yes" title=""/>
<typedefs title=""/>
<enums title=""/>
<functions title=""/>
<variables title=""/>
<membergroups visible="yes"/>
</memberdecl>
<detaileddescription title=""/>
<memberdef>
<inlineclasses title=""/>
<typedefs title=""/>
<enums title=""/>
<functions title=""/>
<variables title=""/>
</memberdef>
<authorsection visible="yes"/>
</namespace>
<!-- Layout definition for a file page -->
<file>
<briefdescription visible="yes"/>
<includes visible="$SHOW_INCLUDE_FILES"/>
<includegraph visible="$INCLUDE_GRAPH"/>
<includedbygraph visible="$INCLUDED_BY_GRAPH"/>
<sourcelink visible="yes"/>
<detaileddescription title=""/>
<memberdecl>
<classes visible="yes" title=""/>
<namespaces visible="yes" title=""/>
<constantgroups visible="yes" title=""/>
<defines title=""/>
<typedefs title=""/>
<enums title=""/>
<functions title=""/>
<variables title=""/>
<membergroups visible="yes"/>
</memberdecl>
<memberdef>
<inlineclasses title=""/>
<defines title=""/>
<typedefs title=""/>
<enums title=""/>
<functions title=""/>
<variables title=""/>
</memberdef>
<authorsection/>
</file>
<!-- Layout definition for a group page -->
<group>
<briefdescription visible="yes"/>
<groupgraph visible="$GROUP_GRAPHS"/>
<detaileddescription title=""/>
<memberdecl>
<nestedgroups visible="yes" title=""/>
<dirs visible="yes" title=""/>
<files visible="yes" title=""/>
<namespaces visible="yes" title=""/>
<classes visible="yes" title=""/>
<defines title=""/>
<typedefs title=""/>
<enums title=""/>
<enumvalues title=""/>
<functions title=""/>
<variables title=""/>
<signals title=""/>
<publicslots title=""/>
<protectedslots title=""/>
<privateslots title=""/>
<events title=""/>
<properties title=""/>
<friends title=""/>
<membergroups visible="yes"/>
</memberdecl>
<memberdef>
<pagedocs/>
<inlineclasses title=""/>
<defines title=""/>
<typedefs title=""/>
<enums title=""/>
<enumvalues title=""/>
<functions title=""/>
<variables title=""/>
<signals title=""/>
<publicslots title=""/>
<protectedslots title=""/>
<privateslots title=""/>
<events title=""/>
<properties title=""/>
<friends title=""/>
</memberdef>
<authorsection visible="yes"/>
</group>
<!-- Layout definition for a directory page -->
<directory>
<briefdescription visible="yes"/>
<directorygraph visible="yes"/>
<memberdecl>
<dirs visible="yes"/>
<files visible="yes"/>
</memberdecl>
<detaileddescription title=""/>
</directory>
</doxygenlayout>

20
docs/source/groups Normal file
View File

@@ -0,0 +1,20 @@
/// @defgroup flatbuffers_cpp_api C++ API
/// @brief FlatBuffers API for C++
/// @defgroup flatbuffers_csharp_api C# API
/// @brief FlatBuffers API for C#
/// @defgroup flatbuffers_go_api Go API
/// @brief FlatBuffers API for Go
/// @defgroup flatbuffers_java_api Java API
/// @brief FlatBuffers API for Java
/// @defgroup flatbuffers_javascript_api JavaScript API
/// @brief FlatBuffers API for JavaScript
/// @defgroup flatbuffers_php_api PHP API
/// @brief FlatBuffers API for PHP
/// @defgroup flatbuffers_python_api Python API
/// @brief FlatBuffers API for Python

48
docs/source/style.css
View File

@@ -1,13 +1,13 @@
body,
body,
#projectname,
table,
div,
p,
dl,
.title,
.tabs,
.tabs2,
.tabs3,
table,
div,
p,
dl,
.title,
.tabs,
.tabs2,
.tabs3,
#nav-tree .label {
font-family: roboto, sans-serif;
}
@@ -44,12 +44,12 @@ dl,
font-size: 14px;
}
.tabs,
.tabs2,
.tabs3,
.tablist li,
.tabs,
.tabs2,
.tabs3,
.tablist li,
.tablist li.current a {
background-image: none;
background-image: none;
}
.tablist {
@@ -106,8 +106,8 @@ div.header {
right: 10px;
}
#MSearchBox .left,
#MSearchBox .right,
#MSearchBox .left,
#MSearchBox .right,
#MSearchField {
background: none;
}
@@ -165,9 +165,9 @@ a.SelectItem:hover {
margin-bottom: 8px;
}
a:link,
a:visited,
.contents a:link,
a:link,
a:visited,
.contents a:link,
.contents a:visited,
a.el {
color: #0288d1;
@@ -197,7 +197,7 @@ div.contents {
}
.directory tr#row_0_ {
border-top-color: #7cb342;
border-top-color: #7cb342;
}
.directory tr#row_0_ td {
@@ -276,7 +276,7 @@ table.doxtable td {
}
.memberdecls tr:not(.heading) td {
background-color: rgba(255,255,255,.95);
background-color: rgba(255,255,255,.95);
}
h1, h2, h2.groupheader, h3, h4, h5, h6 {
@@ -366,7 +366,7 @@ div.line {
code, pre {
color: #455a64;
background: #f7f7f7;
font: 400 100%/1 Roboto Mono,monospace;
font: 400 100% Roboto Mono,monospace;
padding: 1px 4px;
}
@@ -375,7 +375,7 @@ span.preprocessor, span.comment {
}
span.keywordtype {
color: #0097a7;
color: #0097a7;
}
.paramname {
@@ -383,7 +383,7 @@ span.keywordtype {
}
.memTemplParams {
color: #ef6c00;
color: #ef6c00;
}
span.mlabel {