-
Notifications
You must be signed in to change notification settings - Fork 60
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
FR: Support for bitfields? #120
Comments
Hi, I can try to think what it might require to support bit fields but can’t you workaround the issue by serializing them as plain bytes, for example by bit casting before serialization/deserialization? |
I think we could do, but then wouldn't converting them into raw bytes defeat the point of using a serialisation library? We're using this because we want to avoid any problems that might arise out of endianness etc. if we just pass a pointer to a struct as a void* and a sizeof() to the fucntion that puts data onto the wire, and it's really nice how it truly is a two-line job to push data onto the vector and get the bytes off with this lib! So if possible I think this would be a nice addition, but for now we will just do some checks and some bit manipulation on either side to ensure that we don't exceed the min and max values. |
Hi, How about adding condition that serialize trivially_copyable types of size 1 using just std::bit_cast. |
Hi, I would also like this this feature for the serialization/deserialization of highly compact data like: struct Data{
int flag: 1;
int val : 7;
int device_id_0 : 20;
int address : 4;
}; Currently I have to do the bit operation after the deserialization. It would be really nice if this can be done internally. |
We have some types to serialise, and we'd ideally like to use bitfields - as this matches how we really want to use the data, so prevents other sorts of errors from trying to pack values in and risking getting this wrong.
If I try to serialise a type containing a bitfield, I get back errors about taking non-const references to a bitfield, which is illegal given that a reference or pointer to the encasing type (e.g. a 32-bit word) won't point to a real subobject of that type, and so trying to mutate it would result in undefined behaviour.
Do you reckon there is any chance that the library would be able to support types with bitfields in some manner? Or would that require such an amount of reworking that goes against the current design that it's out of scope?
Thanks!
The text was updated successfully, but these errors were encountered: