Re: [linux-audio-dev] (OT) C++ flame war

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] (OT) C++ flame war
From: Martijn Sipkema (msipkema@sipkema-digital.com)
Date: Fri Feb 07 2003 - 01:09:43 EET


[...]
> 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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Fri Feb 07 2003 - 01:10:48 EET