Unions that contain a"type" member

I have a qu开发者_如何学Pythonestion about something I still don't understand about unions. I've read about a lot of their uses and for the most part can see how they can be useful and understand them. I've seen that they can provide a primitive "C style" polymorphism. The example of this that I have seen on a couple websites is SDL's event union:

typedef union {
 Uint8 type;
 SDL_ActiveEvent active;
 SDL_KeyboardEvent key;
 SDL_MouseMotionEvent motion;
 SDL_MouseButtonEvent button;
 SDL_JoyAxisEvent jaxis;
 SDL_JoyBallEvent jball;
 SDL_JoyHatEvent jhat;
 SDL_JoyButtonEvent jbutton;
     SDL_ResizeEvent resize;
 SDL_ExposeEvent expose;
 SDL_QuitEvent quit;
 SDL_UserEvent user;
     SDL_SysWMEvent syswm;
} SDL_Event;

What I cannot understand is how there can be a "type" member up there coexisting with the event types? Aren't these each only allowed to exist one at a time since they occupy the same area of memory? Wouldn't the union exist at any time as EITHER a type or one of the events?

I understand that each event is actually a struct with a type member, for example:

// SDL_MouseButtonEvent

typedef struct{
     Uint8 type;
     Uint8 button;
     Uint8 state;
     Uint16 x, y;
} SDL_MouseButtonEvent;

How does this somehow make sense? Does this somehow allow the type member of the union represent the type of whatever struct the union is currently? Is this some sort of bizarre effect that happens when every member of the union except one is a struct and each struct contains that one member?

Can you access struct members without knowing which struct the object is?

Thanks!

If each of the event types has a Uint8 as its first data member, then the type member of the union is just a convenience.

The general rule with unions is that you can only access the data in the union using the last data member to which you wrote. So, if you last wrote to active, you couldn't next read from key.

An exception to this rule is that if several members of a union share the same prefix (if their first data member(s) are the same), you can access that prefix via any of the data members of the union that share the prefix. So, here, you could refer to active.type or key.type, regardless of which data member of the union is active, and it would work.

The type member of SDL_Event is just a convenient shortcut that allows you to access that type field without having to qualify it as event_object.active.type or event_object.key.type. You can just use event_object.type.

Let's look at how the union is layed out in memory:

Address:    Uint8    MouseButtonEvent   KeyboardEvent
x+0x0       type     type               type
x+0x1       -        button             ?
x+0x2       -        state              ?
...

It just so happens that the type members all line up, so regardless of what type it is, accessing the union as a Uint8 will yield the actual type of the event.

If each of those SDL_xyz struct's first couple of bytes are their own type field, that means that when the union contains one of those objects, the union's first couple of bytes are the same first couple of bytes as the SDL struct - i.e. the type field.

The union doesn't contain both, it just contains the SDL object whose first member happens to coincide in type, size and location with the 'type' field.

Unions in C/C++ are required by the standard to be.aligned to the strictest type they contain. Furthermore, as members of structures cannot be reordered and due to the requirements of the current standards(changing in C++0x) that unions only contain POD types, the idea is that the type member of the union maps to the type member in the struct decks it contains.

As far as the union is concerned, there is no real difference between a struct and a primitive type. The SDL_MouseButtonEven struct is just a bunch of types one after the other.
The type member of the union takes the place of the type member of the event structs. to put it graphically, it looks like this:

SDL_Event union:
  type:    |--------|
  motion:  |--type--|-button-|--state-|-------x--------|-------y--------|  
  active:  |--type--|----------something-else-of-another-event--|          
  key:     |--type--|--maybe-a-smaller-event-|                             
  ... etc'

[Edited, thanks to James' comment.]

The Standard makes some special guarantees on unions so that this sort of thing is safe.

The important rule is that if two POD structs in a union start with the same member types, you are allowed to use the "common initial sequence" of shared members. So if key.type was set, it's legal to read button.type and it will have the same value.

Also, the plain data member (of a fundamental type) type directly in the union must be laid out in memory as though it were in a struct containing just that member. In other words, type is also equivalent to key.type and button.type, etc.