I haven't looked at the validator yet, but it should not be more complicated than what I mentioned for decoding. Keep a set of already visited table offsets, if you see that FBS has recursive definitions.
Btw. there is another caveat to being able to represent cycles. We will not be able to export binaries to JSON if they have cycles.However if the binary represents a graph and not hierarchical tree, the JSON export becomes not really suitable anyways.
I used C# as reference because this was the one that I was most familiar with. However it implies that C# code will not be able to decode binaries which are encoded with C++ and have very high offset numbers. This is a bug.
Now for the next version of FlatBuffers, I think it would be interesting to debate if having offsets as signed int32 would make sense because of the possibility to represent cycles.
As to the complexity during validation. As I mentioned before the overhead comes only if user defines recursive table definitions. If high performance is your goal, avoid recursion.
Actually for real high throughput applications, people should stick with structs as much as possible.
However if it is about flexibility cycles is as important feature as being able to define unions or almost as important as backwards and forwards compatibility.
--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Java and C# do it wrong, even though uint is a type in those languages.
Now what I am interested more is the rational why cycles has to be prohibited?I understand that if in next version of flatbuffers will switch to signed offset, it will become not forwards compatible.Is this the only reason, or are there any performance concerns that I am not aware of.
Java and C# do it wrong, even though uint is a type in those languages.Java has no uint.
Now what I am interested more is the rational why cycles has to be prohibited?I understand that if in next version of flatbuffers will switch to signed offset, it will become not forwards compatible.Is this the only reason, or are there any performance concerns that I am not aware of.Yes, this will not be backwards compatible. Signed table offsets are outside of the FlatBuffers spec, and thus produce corrupt binaries that will crash many implementations, present and future.
Even if we were to make a FlatBuffers v2 format that allows signed offsets, I am not sure if we'd want to. Currently the C++ verifier for example is simple & fast (because no cycle tracking required), and can guarantee that traversals are finite, and within a certain bound of steps. That is very important for applications of FlatBuffers that are susceptible to DOS attacks.
Most serialisation formats only allow trees. FlatBuffers allows DAGs which is already pretty cool, and allows cyclic graphs using indices into vectors. I don't feel native cyclic graph support is worth it.
table Root {
people :[Person];
}
table Person {
name : string;
friends : [uint];
}
root_type Root;
table Root {
people: [Person];
relationships : [Relationship]
}
table Person {
name : string;
}
table Relationship {
freinds : [uint];
}
root_type Root;
table Person (allow_cycles) {
name : string;
friends : [Person];
}
root_type Person;
Wouter
--