-
Notifications
You must be signed in to change notification settings - Fork 3
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
An endianness abstraction #74
Comments
Hm. I think I want the enum, but perhaps the protocol is premature. I'm not sure <Endianess> should be encouraged. |
oscbyspro
added a commit
that referenced
this issue
Aug 28, 2023
oscbyspro
added a commit
that referenced
this issue
Aug 28, 2023
Closed
oscbyspro
added a commit
that referenced
this issue
Aug 30, 2023
oscbyspro
added
maybe
to do, or not to do?
and removed
maybe
to do, or not to do?
labels
Aug 30, 2023
Hm. I'll remove the |
An interesting observation: raw values make enum comparisons much faster prior to Swift 5.8. Meh. |
oscbyspro
added a commit
that referenced
this issue
Sep 3, 2023
oscbyspro
added a commit
that referenced
this issue
Sep 9, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think I've come up with a nice abstraction for endianness. The idea is that a dynamic enum should be used insofar as it is viable, whereas
NBKBigEndian
andNBKLittleEndian
can be used when performance matters more than binary size (and as a namespace for appropriate methods). As far I can tell, dynamic endianness sensitive collections are viable (#72).The latest edition:
The text was updated successfully, but these errors were encountered: