-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support fixed length arrays within structs? #63
Comments
I agree, this would be nice to have, and a logical fit for structs. It's a bit of a bigger feature though, since it lacks forwards compatibility on the schema side. |
+1 very useful for stuff like transformation matrices etc. |
Yeah, i vote for this feature too. |
Any word on this feature? I have a large definition file where my definitions have strings of pre-specified length (my target is mainly c++). I would love to be able to use just structs, rather than tables. |
sounds very useful! |
Noone has attempted this yet. As I said it is a larger feature at this point, even if initially only implemented for C++, since it be an entirely new datatype supported by FlatBuffers. For simplicity, we could allow it only in structs. We could also allow it in tables (inline, much like a struct), but this can also already be achieved by simply wrapping this array in a struct and then sticking that in a table, which would give identical results. It would not break compatibility, since you already can't change structs once defined, so a struct with such an array by definition is a new struct, and by definition is referenced by a new field in a table. This means that old code simply won't access this new field, so it is "forwards & backwards compatible" on a binary level, in that sense. It of course breaks forwards compatibility in schemas, and it breaks all those schemas with the other language implementations until they support the feature. In fact, if we implemented it in C++ only, all the other code generators will at least need to be aware of it and error-out. We'll need separate tests just for this feature. Then we just need implementation for all functionality, specific to this datatype, which is quite a lot of places. Quite a bit of work, but if any of you are familiar enough with the C++ implementation, it should not be that crazy. If not, I'll eventually get to it, but I can't promise when. |
I almost created a new ticket for this, but it is probably enough just to add a comment here. It would be nice to be able to define a 'static' string attribute in a schema. For example: This seems to be the kind of thing that should be added whenever static length strings/vectors are implemented (just like numbers can be defaulted). |
@gwvo could you start to provide some guidance on how this feature might be implemented. Will there need to be custom fixed size vector and string classes? How will the schema definitions change, etc.? Perhaps if you add more information on how expect this feature to be implemented, some C++ dev will take a crack (unfortunately I'm not a c++ guy). |
@falconair some of that is already above. To be more specific: A new type in the schema language. Before we had On a binary level, this represents exactly the same data as if you had written Rather than reusing the BASE_TYPE_VECTOR for this, I'd introduce a new BASE_TYPE_ARRAY in the C++ code. Then comes the fun work of ensuring this is taken into account in all places that deal with schema types, which is a lot. |
…_distribution support LOCATION CHARACTER UI INCLUDE in copy_resource.py
Where can we store the length of such array after type parsing? |
I think a new |
How about using a new built-in "size" attribute for this and, for structs, allow using vectors but only if they have the size attribute. E.g. |
Feature request: fixed length arrays, especially allowed within structs.
If I want to store a 256-bit hash in a struct, I'd either need to convert to a table in order to use [ubyte], or else store 4 ulongs (which is ugly). Would be convenient if there was a way to store a fixed-length array in a struct.
The text was updated successfully, but these errors were encountered: