If an IDL file uses DOS-style EOLs (CR+LF), line comments need to
ignore the second linebreak character, otherwise, as is currently
the case, the parsed documentation comment includes a trailing `\r`
character, which is then output verbatim into the output source
code by flatc.
Change-Id: I39591631995a980622d20a4a32315178b33f18f6
added bii-travis.sh and readme.md files; added build status section with travis and biicode build
systems
Change-Id: I93acd1ca9497416ade6293d63b5311c4c31b880f
Enums should not be (badly) emulated with classes in C# but should
use native C# enums instead. Java implementation made an explicit
choice not to use the (more complex) Java enums, but C# enums are
just light-weight syntactic coating over integral types.
Fixes issue #171.
Change-Id: I9f4d6ba5324400a1e52982e49b58603cb7d7cca7
- Add parse handling of .proto struct and field doc comments (enums and
their values were already handled)
- Add FBS generation handling of doc comments for structs, their
fields, enums, and their values (requires linking idl_gen_general in
the test binary build)
- Tested using test.proto|golden with doc comments added. Xcode run of
flattest passes.
Change-Id: Idff64dd8064afba227174ab77d2c7be22d006628
Tested by regenerating all tests/ generated sources; note that only
Monster.java changes. Ran flattests as well.
Change-Id: I65b6ea7d208b0ccd6a0b34761162fed6ba391fc5
We were looking for 'flatc' in motive/bin/Debug/flatc,
on Mac. It's actually built to flatbuffers/Debug/flatc.
Tested: OS X Yosemite, ndk-r10d. Also tested on Linux.
Change-Id: I9f1ecfe00c5f42fd9b6808b5a5da1c920487a4c2
(Java doesn't support unsigned types).
ubyte/ushort return as int
uint returns as long
(all with correct masking)
ulong still returns as long, as before.
Tested: on Linux & Windows.
Bug 17521464
Change-Id: Id6bc8f38fc8c1a2f4e6733c6980dc6b6e322b452
BitConverter was excessively slow since it allocates a byte array
at each access.
Bug: 18702381
Change-Id: I47be9c38e1d04287ba4c10bc369848f3e13a2a2f
Tested: on Windows.
There is a bug in creating a C# table when it includes a field of type 'BOOL'. The problem is that the generate C# code is as follows:
"bool SampleValue = 0;"
This will fail to compile, because in C# this fails, it needs to be generated as:
"bool SampleValue = false;"
The error is in line ~510
Change-Id: I77f6eea0f269b0540dbeb462602fc447cb69237d
This function gets around the inefficiency of populating a [ubyte] vector
byte by byte. Since ubyte vectors are probably the most commonly used type
of generic byte buffer, this seems like a worthwhile thing to create a
fast path for.
Benchmarks show a 6x improvement in throughput on x64.
There is a new test verifying the functionality of the function.
Change-Id: I82e0228ae0f815dd7ea89bf168b8c1925f3ce0d7
1. Random table fields are now marked deprecated. The deprecation rate is adjustable, default is ~10% of fields.
2. Vector type previously produced a dummy field, now a trivial ubyte vector is generated instead.
3. The fuzzed "instances" were previously generated with identical data, now they are randomized: I suppose such was the intent from the beginning, just wasn't implemented.
I ran the new test with a few different settings and random seeds (but only on Windows + VS2015), and it always passed.
Change-Id: I2014686b6680aec24049ccda3f6deffe5205a83e
* Tests for Release feature.
* Check vector_downward.buf_ before passing to deallocator.
* Assertions.
* Shared test between unique_ptr and GetBufferPointer()
* Unnecessary using directives.
* Reallocate vector if released on clear operation.
* Use allocator attribute.
* Renamed `Release()` to `ReleaseBufferPointer()`
* For consistency with `GetBufferPointer()`
* Updated documentation for ReleaseBuffer.
Change-Id: I108527778e56ae5127abf9e5b1be6b445ad75cb7
build_apk.sh assumed pre-releases would be sorted towards the end,
but instead they end up at the front (sort -n) causing the api
selection loop to halt early.
bug: 19213196
Change-Id: I210a18c16e81880229f154c4613f8b97d90ac9bd
tested: on Linux.
FlatBuffer schema files can now optionally specify a hash attribute that
will allow someone writing json files to enter a string to be hashed
rather than a specific value. The hashing algorithm to use is specified
by the schema.
Currently the only algorithms are fnv1 and fnv1a. There are 32 bit and
64 variatns for each. Additionally, a hashing command line tool was
added so that you can see what a string will hash to without needing to
inspect the flatbuffer binary blob.
Change-Id: I0cb359d0e2dc7d2dc1874b446dc19a17cc77109d
Added a call to $(strip) to the parameters of
`flatbuffers_header_build_rules` so that newlines can be used when
passing arguments to it.
Change-Id: Ie2149acebcef91d28ce2cb4bfd204a209b4c4e2f
Previously, if you were re-using instances of FlatBufferBuilder
and an earlier buffer would use a 64bit item where later ones
do not, you could be wasting space.
Change-Id: Ic8090a38f97ce73194e991ba72bcfae74a7ace9f
Tested: on Linux.
getRootAs..() function now has a second implementation that
accepts an existing object to allow object reuse, much like
all other methods that refer to objects.
Change-Id: Iffef567c903a130761ef7de98867e5465d29a04d
Previously Android.mk only had a rule for the Flatbuffers test. There
is now an empty module definition so that flatbuffers can be included
as an Android module in other projects.
Additionally, android/jni/include.mk has been added which contains
some utility functions that can be used by projects using Flatbuffers
to generate header build rules and set up dependencies.
A sample project has been added to the samples directory to
demonstrate how to use flatbuffers with Android.
Tested by compiling Android project on Linux.
Change-Id: I25d6da40f6531777b22f7371187e0a2f4e903ad4
The satellite data of the ``ByteBuffer`` cannot be modified in
any way and stay thread safe in the presence of concurrent readers.
This implementation is simple and does introduce an allocation, however
without it multiple readers will quickly and continuously encounter
``IndexOutOfBoundsException`` exceptions.
An alternative, but possibly more controversial, implementation would
be to use ``Unsafe``. Using ``Unsafe``, it's possible to do an
array copy with a provided buffer index.
Change-Id: I851d4034e753b3be2931ee2249ec2c82dde43135
optimization would cause vtable fields from previous tables to be written.
Bug: 19046968
Change-Id: I781f7bcbceeaec0b499d4f1e4e5e8a1e750e0707
Tested: on Linux.
If the schema didn't contain a namespace, paths would contain a
leading /, causing files not to be written.
Change-Id: I508772cbf6d18d464ef7d9f8842d0dbff14358a3
Tested: on Linux.
Bug: 19067493
Jason Sanmiya