Yes, it quite certainly was!
I don't care! :p It's allows whatever-you-like variable names and it's safe to use, and portable too (or should be anyway).Quote:
But that would be inefficient compared to <forcibly stops typing> :D
Printable View
Yes, very portable, safe, and good. :)
Maybe you could lend some of your structure-member-accessing-by-offset expertise here . . . http://cboard.cprogramming.com/showthread.php?t=94972
Unfortunately, I think most about the structures has been said already... I can't think of a portable solution right now, either... Unless it's possible to use unions to group together chars, but I'm not too knowledgable about them.
Sorry, it's not.
Basically, as far as the standard is concerned, the ground rule is that if you access anything through a different type than it actually is, it's undefined. The only two exceptions are where
1) we're talking about base and derived class pointers/references and
2) we're talking about the extremely elusive structural conformance concept. Which is really still about the type being the same, but as members of different structures. And there are very stringent restrictions on these structures.
I'm thinking of the unions that are usually declared (and used by) Windows API in its headers:
If it's possible to declare all the members are char, then you might be able to avoid padding (at least until the end), while still being able to access the data through members with other type. Dunno if it's possible. Otherwise I can't think of another solution than to force padding.Code:typedef union _ULARGE_INTEGER {
struct {
DWORD LowPart;
DWORD HighPart;
};
struct {
DWORD LowPart;
DWORD HighPart;
} u;
ULONGLONG QuadPart;
} ULARGE_INTEGER,
*PULARGE_INTEGER;
That union is fine as long as two DWORDs does not require a different alignment than a ULONGLONG. Which holds true as long as the machine can handle DWORD without it being aligned to anything bigger - which again holds true for all machines that currently can (or in the past have been able to) run Windows. By the way, unportable constructions are VERY common in header files that belong to the OS - because they can rely on the OS and the compiler having to adhere to certain standards.
--
Mats