Hi, I'm using your keil IDE for stm32 programming.To improve the readability and safty of my code, I always like to use enum type. Sometimes I need to transfer data from the mcu to my pc, and in some wireless app, the number of bytes that can be transfered is fixed. I want to use struct and enum for the transfered data, so I need to strictly defined the sizeof my user-defined enum type. That is, I want to specify the underlying type of the enum type. But this is not available in the iso 2003 standard. I've tested that the default underlying type has the smallest sizeof(enum_type_name) that can represent all the enumerator values defined in the enumeration. But you know, things Without Any Warranty is not good. So I wrote this e-mail to suggest that mdk C++ compiler should support the new c++ standard.
last, for the explicitness of what I mean: I need the define an enum type like this, enum Direction: char{ /* underlying type is char, so sizeof(Direction) is 1 */ LEFT, RIGHT }; this code is valid when i wrote it in visual studio, but it cannot be compiled use mdk.
you can refer to “7.2 Enumeration declarations” of the doc ISO/IEC 14882 - Information technology — Programming languages — C++
sincerely, Pony279 from china.
Thanks, I see,
from c-faq.com/.../padding.html : " If you're worried about wasted space, you can minimize the effects of padding by ordering the members of a structure based on their base types, from largest to smallest. "
So I wonder whether correctly ordering the members of a structure avoids sturcture padding completely.
"So I wonder whether correctly ordering the members of a structure avoids sturcture padding completely."
Only in some situations.
If you have 3 byte variables and then a 32-bit variable, then a compiler for a normal 32-bit processor will insert a pad byte to get the 32-bit variable to start at offset 4. If you have that 32-bit integer first, then the struct will still get a pad byte last, to make sure that the full struct is n*4 byte large in case you use it in an array.
Starting with all large variable types and going to smaller types tends to minimize the amount of pad - but is not enough to guarantee that no pad is needed. And different architectures have different rules for how much padding is needed because of differences in cost for unaligned access.
I wonder how you could possibly justify starting that sentence with "So", indicating it was some kind of conclusion of the one you quoted. It's not; and by a quite a margin.
First of all, "correctly" has no place in that sentence. There's neither a correct, nor an incorrect ordering to be found here. All orderings are equally correct, period.
As to "avoiding [...] padding completely": do you really believe the C FAQ would have said "minimize" if what they actually meant was "avoid completely"?