[colug-432] c++ struct serialization?

[Chris Punches]

I missed the question about serialization of a struct:
https://accu.org/index.php/journals/2317

I'm not sure why you'd want to do that though because I don't know what
your solution is doing.

-C

On Fri, Dec 13, 2019 at 12:43 AM Chris Punches <punches.chris at gmail.com>
wrote:

> Sizeof for a struct is going to be implementation dependent.  The C
> standard leaves to the compiler to define padding to avoid alignment
> issues.  Padding will be added when one of the members is followed by
> another member with a larger size or at the end of the struct.
>
> What problem are you really trying to solve, though?
>
> Also, just nit-picking, in the future please share your actual code so
> that we can run it through analyzers or check it locally.
>
> -C
>
> On Fri, Dec 13, 2019 at 12:25 AM Rick Hornsby <richardjhornsby at gmail.com>
> wrote:
>
>> I can do higher level languages like Python/Ruby “scripts”, but when
>> it comes to C/C++ it seems like a different world. Probably because
>> I’ve spent so little time in that world, especially over the last
>> several years.
>>
>> This is an Arduino/ESP32 project, but the trouble I’m having is with
>> my C++. I’ve been trying for a few days to understand what’s happening
>> in this example -
>>
>>
>> https://github.com/espressif/arduino-esp32/blob/master/libraries/Preferences/examples/Prefs2Struct/Prefs2Struct.ino
>>
>> I understand enough of it to know that I'm trying to do something
>> similar with an ESP32 microcontroller project, where when a command
>> comes over the network to change a setting (that part is done and
>> working), that setting is persisted to EEPROM (“preferences”) so that
>> when power is lost, it will resume what it was doing when it starts
>> back up. My struct is similar to the example:
>>
>> typedef struct {
>>     u8_t mode;
>>     u16_t activation_threshold;
>>     u8_t scheme_in_use;
>>     // u8_t custom_scheme[9]; // 3*RGB, could probably be 3*24bit (32)
>> ints.
>> } settings_t;
>>
>> One difference is that ‘activation_threshold’ in mine is a 16 bit int,
>> whereas the example they’re all 8 bits.
>>
>> This creates a really, really weird thing I can’t figure out to where
>> the sizeof() the struct is 1 byte for every 8 bit value, but if
>> there’s a 16 bit value, there are 2 extra bytes. For example, if we
>> ignore the 9 byte array ‘custom_scheme’ - we should have a 4 byte
>> struct. For whatever reason, it’s 6. If I split activation_threshold
>> into two 8 bit ints, the size of the struct is 4 bytes. Playing around
>> with the struct, making one 32bit, moving that 32 bit to a different
>> position in the struct, etc is coming up with different sizes. I
>> suspect there’s some kind of memory allocation thing happening that I
>> don’t understand.
>>
>> Either way. The more pressing but related thing is that I’m struggling
>> to figure out how to serialize the struct into a byte array (?), and
>> un-serialize it back from a byte array into a struct. This terrible
>> looking monstrosity is all I’ve been able to figure out for the
>> retrieval part:
>>
>> size_t settingsLen = prefs.getBytesLength("settings");
>> char buf[settingsLen];
>> prefs.getBytes("settings", buf, settingsLen);
>> settings.mode = buf[0];
>> settings.activation_threshold = (buf[1] << 8) | (buf[2] & 0xff);
>> settings.scheme_in_use = buf[3];
>> settings.custom_scheme[0] = buf[4];
>> // …and so on.
>>
>>
>> There’s no way the code should be this primitive … or better put,
>> dumb? But if I try to follow the example more closely, using the cast
>> like he does on line 29 of the example, the 16 bit value and
>> everything after it is all screwy. It doesn’t seem to be as simple as
>> the bytes go back into the slots of memory where they should?
>>
>> Any ideas?
>>
>> Thanks!
>>
>> _______________________________________________
>> colug-432 mailing list
>> colug-432 at colug.net
>> http://lists.colug.net/mailman/listinfo/colug-432
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20191213/c541bb26/attachment-0001.html