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.

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.

>Yup. That's why we're just stabbing the dark. I just thought of creating a custom class which would have some huge property, something to keep half a meg of something, and to instantiate two or three objects out of it... so if we have a tool which is not precise, we may have to give it couple of huge things to measure.