multi-dim arrays #20
Comments
|
I've opened a separate issue to discuss the C++ array library issue (#22). Regarding the computed field syntax for accessing array values, it was a deliberate choice to allow the dimensions to be given in any order when they are specified by name. But I can see that being confusing. We can make a change to require them to always be provided in the correct order. |
johnstairs
added a commit
that referenced
this issue
Dec 8, 2022
Based on feedback, we now require array access index arguments to be
given in the correct order, even when dimension names are used.
For example, this would no longer be valid:
```yaml
MyRec: !record
fields:
arrayField: !array
items: int
dimensions: [x, y]
computedFields:
accessArrayElementByName: arrayField[y:1, x:0]
```
Note that the `x` and `y` arguments are provided out of order. You will
now have to write `arrayField[x:0, y:1]`
Addresses #20
|
Fixed in referenced PR. Will be part of next release. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://github.com/microsoft/yardl/blob/main/docs/docs.md#computed-fields states
this swaps the order between
dimensionsand access. Is this intentional? It'd be very confusing!Also, somewhere in the doc we'll need a description of mappings between yardl types and C++ and other target languages. In particular, I believe you generate your own multi-dim array type as there still doesn't seem to be an
stdcontainer sadly.It could be useful to support a few existing multi-dim arrays to avoid copies in client-code (Boost.MultiArray and https://amypad.github.io/CuVec/ come to mind), but I can see that becoming very difficult. (If a mapping to a flat array is exposed somewhere, it'd need to be stated if row-major or column-major order is used).
The text was updated successfully, but these errors were encountered: