Author: Eugene Nalimov
Date: 16:31:03 12/02/99
Go up one level in this thread
Unfortunately, anonymous struct is not part of the C standard; only anonymous
union is. So, if you want your program to be 100% ANSI/ISO C, you have to name a
struct. If you don't want to write struct name on any access, you can define set
of macro for fields access.
BTW, such a union will help your program on any RISC/EPIC architecture - e.g.
Alpha, MIPS, IA-64, etc. Without it compiler have to assume that your structure
is 1 byte-aligned, so in a lot of cases it'll have to generate unaligned loads
for structure assignment, argument passing, etc. (Strictly speaking that's not
necessary the case, but majority of compilers will do that). But please notice
that on some systems (sizeof(int) == 8), so you'll lose some memory there.
Eugene
On December 02, 1999 at 18:47:16, Tom Kerrigan wrote:
>The only reason I don't want to name the struct is to make the code more compact
>and intuitive.
>
>If your compiler supports structure assignment, then maybe copying these moves
>is as fast as copying integers. Otherwise you might have to copy all 4 fields to
>make the compiler happy, and that would cost a lot. And comparing two of these
>structures would cost more than comparing two integers for the same reason.
>
>-Tom
>
>
>On December 02, 1999 at 16:51:05, Dann Corbit wrote:
>
>>On December 02, 1999 at 16:21:48, Tom Kerrigan wrote:
>>
>>>I'm currently using the following to define a move:
>>>
>>>typedef union {
>>> int i;
>>> struct {
>>> char from;
>>> char to;
>>> char promote;
>>> char flags;
>>> };
>>>} move_t;
>>>
>>>This allows the structure to be treated as an integer, so moves can be copied
>>>and compared easily.
>>>
>>>However, I just noticed that VC++ 5.0 produces a level 4 warning because the
>>>struct is unnamed.
>>>
>>>How bad is this? Will some compilers not compile my stuff because of it?
>>
>>Unnamed structs are a non-standard extension. Some compilers won't compile it,
>>but most won't give you a problem. There is an icky(tm) solution:
>>typedef struct {
>> char from;
>> char to;
>> char promote;
>> char flags;
>>} smove_t;
>>
>>typedef union {
>> int i;
>> smove_t m;
>>} move_t;
>>
>>typedef union {
>> int i;
>> struct {
>> char from;
>> char to;
>> char promote;
>> char flags;
>> };
>>} bmove_t;
>>
>>here, a move_t is fully standard, but you have to address a struct piece with
>>the prefix m to use it as the struct. In the second case, a bmove_t is
>>non-standard but usage is more transparent.
>>
>>Even more interesting is that there is no guarantee that the smove_t will fit
>>into an integer even if the integer is 4 bytes long (although it would be very
>>strange if it did not). There are no restrictions on padding of structs defined
>>in the language definition [or even the physical ordering of the members!
>>That's why the offsetof() macro is needed]. Also, type int could be anywhere
>>from two to 8 octets on standard compilers currently in existance.
>>
>>I think you will find that if the struct actually fits into an integer, then
>>operations on the struct will be about as efficient as operations on the int
>>(example -- exchange two items in an array). It is possible that the union with
>>an int will force alignment restrictions that improve efficiency.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.