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
encoding/binary: make type error clearer #4825
Labels
Milestone
Comments
structs containing slices are not fixed-size values: the size varies depending on the size of the slice. If you really only have 3 Analogs and 8 Digitals then you can use an array. If the length is variable, then there are many possible ways to encode it, and encoding/binary is not going to pick one. It is for fixed-size values. For encoding of richer values, consider encoding/gob or encoding/json. Status changed to WorkingAsIntended. |
The example of 3 Analogs and 8 Digitals was just for ease of understanding. I am parsing a Comtrade binary data file. http://en.wikipedia.org/wiki/Comtrade and the linkt to the standard http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=798772&isnumber=17337 The number of Analogs and Digitals is specified in the Config file. And I really dont have control of how they do the encoding, I cannot force them to encode using gob or json, I wish I could. I really have a work around and everything works. It just was frustrating that the runtime errors were not really helpful. Since I do pass in a slice of structs with arrays and it works, but a slice of structs with slices does not work, which is indeed working as designed. I have a fixed size struct, but its size is not known as a constant expression. This is the root problem. Thanks for all your work and really elegant APIs, I like them and I am enjoying programming in Go. |
This issue was closed by revision 2b9787c. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by shakeel.mahate:
The text was updated successfully, but these errors were encountered: