6 Feb
2003
6 Feb
'03
7:19 p.m.
[...]
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