Struct field containing size of struct

Hello,

Why might a struct need a field containing the size of the struct (for example, in Windows programming, the first field of the struct WNDCLASSEX is generally set to sizeof(WNDCLASSEX))? Can the size of a struct not usually be found in a symbol table or the like?

Thanks for any help.

It means microsoft can keep adding new members to the end of the structure, which new code will use (and write a bigger size).

Old code does NOT have to be recompiled, but it will still work since the MS code will read the old (small) size and thus overlay the appropriate old structure.

I see. Does this mean the new code will be compiled with a new definition of the structure (containing the additional members), which is different from the definition used for compilation of the old code?

It could just be the new one, with some flags to prevent access to non-existent members, or both structs, with one renamed to indicate a previous version.

The point is, the old and new structs overlap exactly, so in effect you have

Code:

---

union {
  struct old {
    int foo;
  };
  struct new {
    int foo;
    int bar;
  };
}

---

So you can have two structure declarations (or class definitions) with the same name in different files, with one having additional members? My compiler doesn't complain about this for C or C++; I would have thought it would contravene the one-definition rule in C++ at least.

That would be one way of doing it, yes.

The one definition rule is per translation unit. Two source files could each have their own "struct foo" without conflicting with the other.

I had two files with following:

Code:

---

#include <stdio.h>
#include <stdlib.h>

struct point {int x; int y; int z;};
extern struct point p2;

int main()
{

    struct point p1 = {0, 0, 0};

    p1.x = p2.x;
    printf("%d", p1.x);
    return 0;

}

---

and:

Code:

---

struct point {int x; int y;};
struct point p2 = {99, 99};

---

So I would have thought translation units and files would have been equivalent in this case, i.e. two translation units with conflicting definitions. I had pretty much exactly the same thing in C++ too. Compilation and linking worked OK in both cases.

But the compiler can only check the current source file for internal consistency.

By the time you get to the linker, all type information has gone. All the linker sees is p2 with 8 bytes of initialised data.

If your main tried to access p2.z, it would get garbage.