When either source or destination or both namespaces were empty, flatc
was generating incorrect TS code.
For example:
```
export namespace {
export import ObjectId = NS10770172024577249292..ObjectId;}
```
In this case the target namespace is empty, and so is the namespace
between the NSxxx placeholder and the target type.
The original implementation of map access is very naive:
- Encode String to UTF8 byte[]
- Creates a new KeyVector
- Performs a binary search to find the key
- return value
So every access to the Map there was useless allocations of Keys and KeyVector
and complete encoding of the search key, which for most comparisons would be wasteful.
This changes completely removes the use of KeyVector and compute the key
positions on the spot. Besides that, it compares keys codepoint-by-codepoint,
avoiding unnecessary allocations and reducing encoding for most cases.
Some benchmarks result in a 2.75x speedup.
* [CMake] : Add precompiled header support with FLATBUFFERS_ENABLE_PCH
FLATBUFFERS_ENABLE_PCH enable precompile headers support for 'flatbuffers' and 'flatc'. Default if OFF.
You need to set it to ON to make it work. 'cmake -DFLATBUFFERS_ENABLE_PCH=ON ..'
This will only work if CMake version is >= 3.16, because target_precompile_headers is used.
If CMake doesn't have target_precompile_headers, then nothing will happen.
This can speed up compilation time.
Precompiled header file for 'flatbuffers' is 'pch.h'
Precompiled header file for 'flatc' is 'flatc_pch.h'
* Enable FLATBUFFERS_ENABLE_PCH for VC 2017 and VS2019 builds
* [CMake]: Fix error in FLATBUFFERS_ENABLE_PCH description
* Add a function add_pch_to_target to avoid copy and pasting the same code like add_fsanitize_to_target
Move pch.h and flatc_pch.h from include/flatbuffers to include/flatbuffers/pch
Make flatc_pch.h depends on pch.h since it extend it
flatbuffers_generate_headers is a function that can be used to generate Flatbuffers headers and binary headers. It uses named argument flags to wrap all the flags relevant to C++ header generation that flatc uses. It generates an interface library that can be added as a dependency of other targets.
flatbuffers_generate_binary_files is a function that can be used to generate Flatbuffers binaries. It uses named argument flags to wrap all the flags relevant to C++ binary generation from JSON file that flatc uses. It generates an interface library that can be added as a dependency of other targets.
Number of elements on the stack shouldn't affect the calculation
of ElemWidth(). Variable 'start' needs to be subtracted from the
loop variable 'i' to make indexing zero-based.
There is an additional unit test to pack nested vectors. Size of
the packed buffer *without* this fix is 798 and only 664 bytes
*with* the fix.
For example:
include/flatbuffers/reflection.h:365:8: error: definition of implicit copy
constructor for 'pointer_inside_vector<flatbuffers::Table, unsigned char>'
is deprecated because it has a user-declared copy assignment operator
[-Werror,-Wdeprecated-copy]
void operator=(const pointer_inside_vector &piv);
^
It's unclear why the old code wanted to declare a public `operator=`
without defining it; that just seems like a misunderstanding of the C++03 idiom
for deleting a member function. And anyway, we don't *want* to delete the
assignment operator; these are polymorphic types that do not follow value
semantics and nobody should ever be trying to copy them. So the simplest fix
is just to go back to the Rule of Zero: remove the declaration of `operator=`
and let the compiler do what it wanted to do originally anyway.
"The best code is no code."
Also, update the generated .h files.
Fixes#5649.
* flatc should generate a 'Create…' method for tables with struct fields when also generating the object based api (C#)
https://stackoverflow.com/questions/60724317/flatc-should-generate-a-create-method-for-tables-with-struct-fields-when-al
* missing namespace fixed: C:\projects\flatbuffers\tests\namespace_test\NamespaceA\TableInFirstNS.cs(30,7): error CS0246: The type or namespace name 'StructInNestedNST' could not be found (are you missing a using directive or an assembly reference?) [C:\projects\flatbuffers\tests\FlatBuffers.Test\FlatBuffers.Test.csproj]
Co-authored-by: stefan301 <Stefan.Felkel@de.Zuken.com>
Including CPack without the additional packaging information creates unused project files, and can potentially cause issues for projects including Flatbuffers that also use CPack.
* Parser reject "nan(n)" string as it does with nan(n)
* Adjust scalar fuzzer to ignore '$schema' substrings
- Scalar fuzzer ignores '$schema' substrings at the input
- Added 'scalar_debug' target to simplify research of fuzzed cases
* Improve formatting of './tests/fuzzer/CMakeLists.txt'
* [Flatbuffer] Generate code for force_align with CreateXDirect and Pack functions.
* Fixed Visual Studio 10.0 compile error for std::to_string.
* Fixed Visual Studio 10.0 compile error for std::to_string.
* Add gen-name-strings for Rust
* Clang format
* Add tests and generate with gen-name-strings
* Clang-format
* Stop doing gen-name-strings with C++ code
* Bring generate_code.bat up with generate_code.sh
* Fixed refractoring issue in reflection/generate_code.sh. Also, mv deletes the original file, so I don't need to clean it up manually in that case.
* Added --filename-suffix and --filename-ext to flatc
* Fixed typo and added example generation of suffix and extension for C++
* Removed extra ;
* Removed clang-format block from a region that didn't need it. Fixed an auto format of another clang-format block
* Added docs, fixed pointer alignment, removed suffix test file
* Adds the basic structure for required to add grpc support
Added the message implementation
Updated the code to confirm to the protocol flatbuffersobject
Adds an example for Swift flatbuffers GRPC
Started implementing the swift GRPC code Gen
Generator generates protocols now
Fixing ci issues
Migrated the logic to use grpc_generator::File instead of string
Refactored swift project
Implemented GRPC in swift
Finished implementing GRPC in swift
Fixes issues
Adds contiguousBytes initializer to swift
Adds documentation + fixes buffer nameing in tables + structs
Adds documentation + fixes buffer nameing in tables + structs
Updated tests
* Updated version
To read and build flexbuffers on Java, one needs to wrap the data
using ByteBuffer. But for the common case of having ByteBuffers
backed by arrays, accessing from a ByteBuffer might be inefficient.
So this change introduces two interfaces: ReadBuf and ReadWriteBuf.
It allows one to read and writes data directly on an array. It also allow
other buffer implementations to be used with flexbuffers.
Another change is that FlexBuffersBuilder backed by array allows
the buffer to grow with the increase of the message size. Something
that could not be done with ByteBuffer.
Previously UnPack would allocate data with new and assign it to a
raw pointer. This behavior makes it possible for the pointer to be
leaked in case of OOM. This commit defaults to use the user specified
pointer (which needs to implement a move constructor, a .get() and a
.release() operators), thus preventing these leaks.
* [C++] Use strong enum type for vectors when scoped-enums is on.
These changes only apply when scoped-enums is on, and thus only
the C++17 tests show diffs.
This may break users who use 1) use scoped-enums and 2) use
vectors of enums. However, it seems that this change should
have been made originally when scoped-enums were added.
Fixes#5285
* [C++] Put strong enum change also behind C++17 flag.
It actually only needs C++11 technically, but this is being done
to avoid breaking any existing users.
Tests were rerun, but produced no additional diffs, as expected.
* [C++] Forgot one location in which C++17 guard needs to go.
This commit produces no additional diffs in generated code.
* Use g_only_fixed_enums instead of scoped_enums.
This means data written with older versions of this code has
potentially misaligned data, which we'll need to support.
This isn't a problem on most architectures, but could be on
older ARM chips. To support them properly may require swapping
out uses of `flatbuffers::ReadScalar` with a version that does a
memcpy internally.
Change-Id: Ib352aab4a586f3a8c6602fb25488dcfff61e06e0
* [C#] support Object API
* fix sign-compare
* fix indent
* add new line before for loop.
* using auto whenever possible
* reduce the amout of blank lines.
* wip: support vectors of union
* done: support unions of vectors
* set C# version to 4.0
* remove null propagation operator
* remove auto property initializer
* remove expression-bodied method
* remove pattern matching
* add Example2 to NetTest.sh
* separate JavaUsage.md and CsharpUsage.md from JavaCsharpUsage.md
* add C# Object based API notes.
* support vs2010.
* remove range based for loop.
* remove System.Linq
* fix indent
* CreateSharedString to CreateString
* check shared attribute
* snake case
* Added the code to embed the binary schema to the source.
This is pulled forward from a old PR #5162 that will be closed.
* Update idl_gen_cpp.cpp
Added a small comment to trigger a new build. The build was failing in a strange location and doesn't look like it has anything to do with the code.
* Moved the EscapeAndWrapBuffer to util.cpp and did some formating.
* One more camelCases removed and renamed some variables.
* wrapped_line_xxx should have been passed as a const reference in the first place.
* Moved the bfbs embed sample to it's own file.
* Missed moving the namespace back.
* Moved the embedded bfbs to test.cpp instead of using a sample.
* Missed adding the generation of embedded bfbs to the build.
* See if this makes the build happier.
* Fixed a in-compatable cpp output of the generated header.
* Did some changes to reflect the code review comments.
1. Update the EscapeAndWrapBuffer to BufferToHexText and fixed a variable name.
2. Moved the include of the embedded binary schema to all the other includes.
* Moved some code to inline the instead of using a local variable.
* Moved the BufferToHexText back to be a inline function in util.h
* [Java][FlexBuffers] Deprecate typed vector strings due to design flaw
It will still be possible to read buffers with this type, but the
elements will be treated as FBT_KEY and will be read as null-terminated
string.
Trying to build a vector of strings as typed will throw an exception.
More information on https://github.com/google/flatbuffers/issues/5627
Also, fix another bug on strings, where long strings were not properly
aligned.
* [Java][FlexBuffers] Make FBT_VECTOR_STRING_DEPRECATED considered typed.
The logic for FlexBuffers.isVectorType() was changed
to not consider FBT_VECTOR_STRING_DEPRECATED a typed
vector, but that can lead to missinterpretation for
existing serialized data. So we are reverting.
Max Burke