* codegen for all basic features: WIP (probably implemented all basic feature)
* JSON parsing: NO
* Simple mutation: NO
* Reflection: NO
* Buffer verifier: NO (will be add later)
* Testing: basic: Yes
* Testing: fuzz: Yes
* Performance: Not bad
* Platform: Supported Linux, OS X, Windows (has 32bit integer limitation)
* Engine Unity: No
flatc --php monster_test.fbs
<?php
//include neccessary files.
$fbb = new Google\FlatBuffers\FlatBufferBuilder(1);
$str = $fbb->createString("monster");
\MyGame\Example\Monster::startMonster($fbb);
\MyGame\Example\Monster::addHp($fbb, 80);
\MyGame\Example\Monster::addName($fbb, $str);
$mon = \MyGame\Example\Monster::endMonster($fbb);
$fbb->finish($mon);
echo $fbb->sizedByteArray();
PHP 5.4 higher
Currently, we do not register this library to packagist as still experimental and versioning problem.
If you intended to use flatbuffers with composer. add repostiories section to composer.json like below.
"repositories": [{
"type": "vcs",
"url": "https://github.com/google/flatbuffers"
}],
and just put google/flatbuffers.
"require": {
"google/flatbuffers": "*"
}
* PHP's integer is platform dependant. we strongly recommend use 64bit machine
and don't use uint, ulong types as prevent overflow issue.
ref: http://php.net/manual/en/language.types.integer.php
* php don't support float type. floating point numbers are always parsed as double precision internally.
ref: http://php.net/manual/en/language.types.float.php
* ByteBuffer is little bit slow implemnentation due to many chr/ord function calls. Especially encoding objects.
This is expected performance as PHP5 has parsing arguments overhead. probably we'll add C-extension.
Basically, PHP implementation respects Java and C# implementation.
Note: ByteBuffer and FlatBuffersBuilder class are not intended to use other purposes.
we may change internal API foreseeable future.
PSR-2, PSR-4 standards.
Implemented simple assertion class (respect JavaScript testcase implementation) as we prefer small code base.
this also keeps CI iteration speed.
we'll choose phpunit or something when the test cases grown.
This allows you to query the generated target for those properties
later, so dependent modules can refer to the directories to, for example,
add them to the include_directories.
Change-Id: I7a6bd34c5c1d08e2ea69b5ad845223297cad1159
This function is designed to be called by projects that use FlatBuffers.
It takes a list of FlatBuffers schemas and a list of schema include
directories, and generates build rules to create generated headers
and/or binary schemas for those files, as well as optionally copying
all of the text schemas into a directory for your use (for example if
you need to parse text schemas within your app).
See function comments for more details.
Change-Id: I181684b916e91d965e14849d8f83ec2c83e9a4a4
local-source-file-path does not expand to correct file paths in
some circumstances so some users override it. Therefore
flatbuffers_header_build_rules has been modified to generate rules
that expand LOCAL_SRC_FILES values with flatbuffers_header_build_rules.
Also, this overrides local-source-file-path to allow nest projects
to build when NDK_OUT is set.
Tested:
Verified a dependent project continues to build.
Bug: 25673744
Change-Id: Ic90186fe96d6e4533f9f3b7ca9ef78084de08a7e
When $(MAKE) is expanded via a macro "make" doesn't know whether
$(MAKE) refers to an instance of the make app and therefore doesn't
pass job server arguments down. This change adds the + prefix to the
command in the receipe in order to indicate $(MAKE) is another instance of
make.
Tested:
Verified flatc builds in parallel from Android builds.
Change-Id: I9f2f4f9680b818fdda7420a75a8bfa995b4644db
+ Add state to the Builder object to track if we are inside a table,
and if we are finished building the buffer.
+ Use this data to check that a buffer is being built correctly.
+ Raise an exception if a buffer is not being built correctly.
+ Test that the exceptions happen as expected.
Based on d236dea.
+ Add state to the Builder object to track if we are inside a table,
and if we are finished building the buffer.
+ Use this data to check that a buffer is being built correctly.
+ Panic if a buffer is not being built correctly.
+ Test that the panics happen as expected.
Based on d236dea13d.
* Added the ability to create a build target for generated headers.
* Made it possible for generated header targets to depend upon each
other or arbitrary build targets.
Tested:
Verified some pretty complex libraries with numerous flatbuffer schema
dependencies build using this macro on Linux with the NDK.
Bug: 25188384
Change-Id: I846855a50808e58c34cdf7086e93e7ea0df69e0d
Because they are represented as `const T *` in the Vector template,
the sizeof(const T *) was accidentally used instead of sizeof(T).
Change-Id: Ib4dc73e1d21396ba2e30c84e5e229c4147204bb1
Tested: on Linux.
This adds an optional argument to generated getters for string fields to
specify the encoding type and overloads the createString() function. It's
now possible to use either JavaScript UTF-16 string objects or C-style
UTF-8 byte arrays (Uint8Array) for string data.
JavaScript uses UTF-16 but FlatBuffers uses UTF-8. This commit tests the code
that does the conversion between the two encodings. The last entry in the array
is tricky because each code point actually requires two UTF-16 code units,
unlike the other examples. The current JSON output of flatc actually handles
this case incorrectly (it generates invalid JSON with UTF-8 code units). The
generated JavaScript code passes these tests fine, however.
This adds a JavaScript language target. The generated JavaScript uses Google
Closure Compiler type annotations and can be compiled using the advanced
compilation mode, which performs type checking and optimizations such as
inlining and dead code elimination. The generated JavaScript also exports all
generated symbols for use with Node.js and RequireJS. This export behavior
can be turned off with the --no-js-exports flag for use with Google Closure
Compiler.
