[...] > If you don't know *every* detail of > a struct, you can't create an instance of one, because you don't know > it's *size*.
And the offset of its members. [...] > So, the basic problem is that it's not the constructor that allocates > memory for the instance; it's the code generated by the 'new' > operator. > > There are ways around this, of course. For example, you can "wrap" the > constructor of a class in a static member of the class, that performs > the instantiation and returns a pointer. The "fake" constructor would > actually give you an instance of a "secret" derived class that > contains the implementation. When dynamically linking C++ classes that imlement an interface you can export create/destroy functions that return/take a pointer to a instance. Note that you should not use virtual destructors instead of a destroy function since the delete function called might not match the new from the dynamically loaded code. > BTW, I believe this is about the way normal constructors work in > Delpih/Object Pascal - which is why you cannot have static instances > at all. No matter what you type, what you get is always a pointer. On of the best things about C++ is having auto storage classes, since it makes resource management much easier/safer. I really don't like Delphi/Object Pascal at all. I'm not sure but I believe with Java it is also not possible to create classes on the stack, but Java has a garabage collector (and that's not always convenient for RT tasks). --ms