>Dragan,
>
>You may be on to something about the non overridden properties just being pointers into the memory block allocated for the class definition. Once the property is modified it gets it's own memory space. I tested it just a little different:
>
>? sys(1016)
>x = createobject( "memtest" )
>? sys(1016)
>y = createobject( "memtest" )
>? sys(1016)
>y.bigprop = space(200000)
>? sys(1016)
>x.bigprop = ""
>? sys(1016)
>
>define class memtest as custom
> bigprop = space(100000)
>enddefine
>
>creating X chewed up 100k, creating Y didn't, changing y.bigprop chewed up another 200k, getting rid of x.bigprop used 130 more bytes. But sys(1016) is never accurate once you start deallocating memory it's rare to ever see it go back down. FoxPro is rather piggish about memory once it's grabbed it.

Yeah... it seems it never forgot the memory diet it had back then when it ran on XTs and 286s... hungry as a child, hungry forever :). I assume it may eventually return those blocks in the next garbage collection (not before that), but then we have no idea when it happens.

>VFP doesn't seem to execute the code of the class definition until the first instance is created. I found other evidence of this using datetime() for a class property while writing a section of the PTF-OOP book. This can also be conjectured by doing a sys(1016) right after starting VFP and before running the prg. For me there's a 6k jump when the prg starts and it doesn't go up to 100k until X is instantiated.
>
>All this may just be an artifact of VFP's string memory handling too.

It seems to count all the string space used into sys(1016), plus the program cache plus who knows what. I've ran this example on a clean restart of VFP (5.0), just to make sure it doesn't mess up the measurement. Ummm... the 6K is probably what it needs to store the compiled program AND the class definition - a program containing a Define Class behaves kind of like a .vcx because it does an implicit "Set Classlib to thisprg.fxp addi", and that may add to the calculation.