Reduced `force_align` in tests to 8, to work with --object-api.

More detail:
https://github.com/google/flatbuffers/projects/6#card-17401359

See also the .md changes in this commit.

Change-Id: Idfa68b2fd3bdb19979833737d3a3cf83ec1d6775

2 files changed, 38 insertions, 32 deletions

diff --git a/docs/source/CppUsage.md b/docs/source/CppUsage.md
index ad47a944..74045129 100644
--- a/docs/source/CppUsage.md
+++ b/docs/source/CppUsage.md
@@ -130,10 +130,10 @@ The following attributes are specific to the object-based API code generation:
     verbatim in the class constructor initializer list for this member.
 
 -   `native_custom_alloc`:"custom_allocator" (on a table or struct): When using the
-    object-based API all generated NativeTables that  are allocated when unpacking 
-    your  flatbuffer will use "custom allocator". The allocator is also used by 
-    any std::vector that appears in a table defined with `native_custom_alloc`. 
-    This can be  used to provide allocation from a pool for example, for faster 
+    object-based API all generated NativeTables that  are allocated when unpacking
+    your  flatbuffer will use "custom allocator". The allocator is also used by
+    any std::vector that appears in a table defined with `native_custom_alloc`.
+    This can be  used to provide allocation from a pool for example, for faster
     unpacking when using the object-based API.
 
     Minimal Example:
@@ -151,8 +151,8 @@ The following attributes are specific to the object-based API code generation:
       typedef T *pointer;
 
       template <class U>
-      struct rebind { 
-        typedef custom_allocator<U> other; 
+      struct rebind {
+        typedef custom_allocator<U> other;
       };
 
       pointer allocate(const std::size_t n) {
@@ -164,7 +164,7 @@ The following attributes are specific to the object-based API code generation:
       }
 
       custom_allocator() throw() {}
-      template <class U> 
+      template <class U>
       custom_allocator(const custom_allocator<U>&) throw() {}
     };
 
@@ -208,12 +208,15 @@ The following attributes are specific to the object-based API code generation:
 
 Finally, the following top-level attribute
 
--   native_include: "path" (at file level): Because the `native_type` attribute
+-   `native_include`: "path" (at file level): Because the `native_type` attribute
     can be used to introduce types that are unknown to flatbuffers, it may be
     necessary to include "external" header files in the generated code.  This
     attribute can be used to directly add an #include directive to the top of
     the generated code that includes the specified path directly.
 
+-   `force_align`: this attribute may not be respected in the object API,
+    depending on the aligned of the allocator used with `new`.
+
 # External references.
 
 An additional feature of the object API is the ability to allow you to load
@@ -499,43 +502,43 @@ To use scalars, simply wrap them in a struct.
 
 ## Depth limit of nested objects and stack-overflow control
 The parser of Flatbuffers schema or json-files is kind of recursive parser.
-To avoid stack-overflow problem the parser has a built-in limiter of 
-recursion depth. Number of nested declarations in a schema or number of 
+To avoid stack-overflow problem the parser has a built-in limiter of
+recursion depth. Number of nested declarations in a schema or number of
 nested json-objects is limited. By default, this depth limit set to `64`.
-It is possible to override this limit with `FLATBUFFERS_MAX_PARSING_DEPTH` 
-definition. This definition can be helpful for testing purposes or embedded 
-applications. For details see [build](@ref flatbuffers_guide_building) of 
+It is possible to override this limit with `FLATBUFFERS_MAX_PARSING_DEPTH`
+definition. This definition can be helpful for testing purposes or embedded
+applications. For details see [build](@ref flatbuffers_guide_building) of
 CMake-based projects.
 
 ## Dependence from C-locale {#flatbuffers_locale_cpp}
-The Flatbuffers [grammar](@ref flatbuffers grammar) uses ASCII 
+The Flatbuffers [grammar](@ref flatbuffers grammar) uses ASCII
 character set for identifiers, alphanumeric literals, reserved words.
 
-Internal implementation of the Flatbuffers depends from functions which 
+Internal implementation of the Flatbuffers depends from functions which
 depend from C-locale: `strtod()` or `strtof()`, for example.
-The library expects the dot `.` symbol as the separator of an integer 
+The library expects the dot `.` symbol as the separator of an integer
 part from the fractional part of a float number.
-Another separator symbols (`,` for example) will break the compatibility 
+Another separator symbols (`,` for example) will break the compatibility
 and may lead to an error while parsing a Flatbuffers schema or a json file.
 
-The Standard C locale is a global resource, there is only one locale for 
-the entire application. Some modern compilers and platforms have 
-locale-independent or locale-narrow functions `strtof_l`, `strtod_l`, 
-`strtoll_l`, `strtoull_l` to resolve this dependency. 
-These functions use specified locale rather than the global or per-thread 
-locale instead. They are part of POSIX-2008 but not part of the C/C++ 
+The Standard C locale is a global resource, there is only one locale for
+the entire application. Some modern compilers and platforms have
+locale-independent or locale-narrow functions `strtof_l`, `strtod_l`,
+`strtoll_l`, `strtoull_l` to resolve this dependency.
+These functions use specified locale rather than the global or per-thread
+locale instead. They are part of POSIX-2008 but not part of the C/C++
 standard library, therefore, may be missing on some platforms.
 
-The Flatbuffers library try to detect these functions at configuration and 
+The Flatbuffers library try to detect these functions at configuration and
 compile time:
 - `_MSC_VER >= 1900`: check MSVC2012 or higher for MSVC buid
 - `_XOPEN_SOURCE>=700`: check POSIX-2008 for GCC/Clang build
 - `check_cxx_symbol_exists(strtof_l stdlib.h)`: CMake check of `strtod_f`
 
-After detection, the definition `FLATBUFFERS_LOCALE_INDEPENDENT` will be 
+After detection, the definition `FLATBUFFERS_LOCALE_INDEPENDENT` will be
 set to `0` or `1`.
 
-It is possible to test the compatibility of the Flatbuffers library with 
+It is possible to test the compatibility of the Flatbuffers library with
 a specific locale using the environment variable `FLATBUFFERS_TEST_LOCALE`:
 ```sh
 >FLATBUFFERS_TEST_LOCALE="" ./flattests
diff --git a/docs/source/Schemas.md b/docs/source/Schemas.md
index 42551c64..66c800da 100644
--- a/docs/source/Schemas.md
+++ b/docs/source/Schemas.md
@@ -84,7 +84,7 @@ parent object, and use no virtual table).
 
 ### Types
 
-Built-in scalar types are 
+Built-in scalar types are
 
 -   8 bit: `byte` (`int8`), `ubyte` (`uint8`), `bool`
 
@@ -321,6 +321,9 @@ Current understood attributes:
     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`).
+    Note: currently not guaranteed to have an effect when used with
+    `--object-api`, since that may allocate objects at alignments less than
+    what you specify with `force_align`.
 -   `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
@@ -404,26 +407,26 @@ binary representation.
 
 When parsing numbers, the parser is more flexible than JSON.
 A format of numeric literals is more close to the C/C++.
-According to the [grammar](@ref flatbuffers_grammar), it accepts the following 
+According to the [grammar](@ref flatbuffers_grammar), it accepts the following
 numerical literals:
 
 -   An integer literal can have any number of leading zero `0` digits.
-    Unlike C/C++, the parser ignores a leading zero, not interpreting it as the 
+    Unlike C/C++, the parser ignores a leading zero, not interpreting it as the
     beginning of the octal number.
     The numbers `[081, -00094]` are equal to `[81, -94]`  decimal integers.
 -   The parser accepts unsigned and signed hexadecimal integer numbers.
     For example: `[0x123, +0x45, -0x67]` are equal to `[291, 69, -103]` decimals.
 -   The format of float-point numbers is fully compatible with C/C++ format.
-    If a modern C++ compiler is used the parser accepts hexadecimal and special 
+    If a modern C++ compiler is used the parser accepts hexadecimal and special
     float-point literals as well:
     `[-1.0, 2., .3e0, 3.e4, 0x21.34p-5, -inf, nan]`.
     The exponent suffix of hexadecimal float-point number is mandatory.
-    
+
     Extended float-point support was tested with:
     - x64 Windows: `MSVC2015` and higher.
     - x64 Linux: `LLVM 6.0`, `GCC 4.9` and higher.
 
--   For compatibility with a JSON lint tool all numeric literals of scalar 
+-   For compatibility with a JSON lint tool all numeric literals of scalar
     fields can be wrapped to quoted string:
     `"1", "2.0", "0x48A", "0x0C.0Ep-1", "-inf", "true"`.