Support native_type for tables when using the C++ object API.

[cosmith-nvidia]

If native_type is specified on a table:

• No object API struct type is generated.
• The object API refers to the table by its native_type.
• UnPack and Create methods are declared but not defined; as they
  must be user-provided.

Addresses #4969

[aardappel]

This generally looks good, wonder if this does what people on the original issue wanted it for @buster3 @iceboy233 @sketch34 @lp35 @meniku

[iceboy233]

Can you turn on --gen-compare and fix the generated code?

[cosmith-nvidia]

Can you turn on --gen-compare and fix the generated code?

Added. This was not working at main prior to this change.

I'm also not sure the behavior for structs was correct: when a flatbuffer struct was annotated with native_type, it was generating a comparator for the flatbuffer struct.

I think the desired behavior would be to only generate comparators for the object API generated types (suffixed with T), and not generate comparators for structs/tables with native_types (which need to define the comparators themselves). Let me know if this interpretation is correct (per the flatc description: Generate operator== for object-based API types.).

[iceboy233]

This was not working at main prior to this change.

I'm also not sure the behavior for structs was correct

Maybe it can be a separate change as it's not working prior.

Is it feasible/align with existing code to allow user to implement the member Pack instead of Create, which looks more symmetrical. Or should Native suffix be appended to the create function (CreateMatrixNative) as the code base seems not doing same name function overload (CreateMatrixDirect)? I haven't used flatbuffers for a long time so not sure. @aardappel

[cosmith-nvidia]

Maybe it can be a separate change as it's not working prior.

Sounds good. Mailed #8681 for this.

Is it feasible/align with existing code to allow user to implement the member Pack instead of Create

Happy to do whatever you and @aardappel suggest. Let me try to draft. I think this will just reverse some of the current dependencies of autogenerated Pack() -> Create(), and require rewriting some of the autogenerated object API type code to use Pack instead of Create.

[aardappel]

@dbaileychess opinion?

[cosmith-nvidia]

Is it feasible/align with existing code to allow user to implement the member Pack instead of Create

@aardappel @dbaileychess I mailed #8754 which reverses the dependency of CreateX and X::Pack methods, which will allow users to define X::Pack (instead of CreateX, which will then call X::Pack) in order to provide a table native_type implementation.

[aardappel]

Generally LGTM!

[cosmith-nvidia]

Generally LGTM!

Thanks! I was hoping we could check in #8681 first (to fix the upstream gen compare issue). And then I will rebase this one and switch it to use the Pack method.

[cosmith-nvidia]

@aardappel rebased onto master w/ the previous two changes, and ready for review. Thank you!

[aardappel]

thanks!