diff --git a/docs/html/md__cpp_usage.html b/docs/html/md__cpp_usage.html index f02436ee0..50a0a13a5 100644 --- a/docs/html/md__cpp_usage.html +++ b/docs/html/md__cpp_usage.html @@ -107,6 +107,7 @@ assert(inv->Get(9) == 9);
Using binary buffers with the generated header provides a super low overhead use of FlatBuffer data. There are, however, times when you want to use text formats, for example because it interacts better with source control, or you want to give your users easy access to data.
Another reason might be that you already have a lot of data in JSON format, or a tool that generates JSON, and if you can write a schema for it, this will provide you an easy way to use that data directly.
+(see the schema documentation for some specifics on the JSON format accepted).
There are two ways to use text formats:
This is the preferred path, as it doesn't require you to add any new code to your program, and is maximally efficient since you can ship with binary data. The disadvantage is that it is an extra step for your users/developers to perform, though you might be able to automate it.
flatc -b myschema.fbs mydata.json diff --git a/docs/html/md__go_usage.html b/docs/html/md__go_usage.html index 8a6625081..5a873b209 100644 --- a/docs/html/md__go_usage.html +++ b/docs/html/md__go_usage.html @@ -81,7 +81,7 @@ 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). Structs do have convenient methods that allow you to construct them in one call. These even 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
.
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). 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:
example.MonsterStartInventoryVector(builder, 5) for i := 4; i >= 0; i-- { builder.PrependByte(byte(i)) diff --git a/docs/html/md__schemas.html b/docs/html/md__schemas.html index 85381e7fa..0ddf7e12e 100644 --- a/docs/html/md__schemas.html +++ b/docs/html/md__schemas.html @@ -112,7 +112,7 @@ root_type Monster;Namespaces
These will generate the corresponding namespace in C++ for all helper code, and packages in Java. You can use
.
to specify nested namespaces / packages.Root type
-This declares what you consider to be the root table (or struct) of the serialized data.
+This declares what you consider to be the root table (or struct) of the serialized data. This is particular important for parsing JSON data, which doesn't include object type information.
Comments & documentation
May be written as in most C-based languages. Additionally, a triple comment (
///
) on a line by itself signals that a comment is documentation for whatever is declared on the line after it (table/struct/field/enum/union/element), and the comment is output in the corresponding C++ code. Multiple such lines per item are allowed.Attributes
@@ -125,6 +125,13 @@ root_type Monster;
force_align: size
(on a struct): force the alignment of this struct to be something higher than what it is naturally aligned to. Causes these structs to be aligned to that amount inside a buffer, IF that buffer is allocated with that alignment (which is not necessarily the case for buffers accessed directly inside a FlatBufferBuilder
).bit_flags
(on an enum): the values of this field indicate bits, meaning that any value N specified in the schema will end up representing 1<<N, or if you don't specify values at all, you'll get the sequence 1, 2, 4, 8, ...The same parser that is parsing the schema declarations above is also able to parse JSON objects that conform to this schema. So, unlike other JSON parsers, this parser is strongly typed, and parses directly into a FlatBuffer (see the compiler documentation on how to do this from the command line, or the C++ documentation on how to do this at runtime).
+Besides needing a schema, there are a few other changes to how it parses JSON:
+strict_json
flag.field: EnumVal
. If a field is of integral type, you can still use symbolic names, but values need to be prefixed with their type and need to be quoted, e.g. field: "Enum.EnumVal"
. For enums representing flags, you may place multiple inside a string separated by spaces to OR them, e.g. field: "EnumVal1 EnumVal2"
or field: "Enum.EnumVal1 Enum.EnumVal2"
.FlatBuffers relies on new field declarations being added at the end, and earlier declarations to not be removed, but be marked deprecated when needed. We think this is an improvement over the manual number assignment that happens in Protocol Buffers (and which is still an option using the id
attribute mentioned above).