In article <2t6lne$sau@highway.LeidenUniv.nl> rcenteno@iris (Rick Centeno (guest account)) writes:
>Hi,
>
>Can anyone tell me whether the following paragraph exerted from the
>ANSI draft standards of 25 Jan 94 makes sense?
>
>"In the second alternative, i.e.
>        delete[] Objects;
>if the dynamic type of the object to be deleted is a class that has a
>destructor and its static type is different from its dynamic type, the
>result is undefined."

 [Note: its not sensible to talk about 'the dynamic type
of an object' .  _Expressions_ have dynamic type -- the type
of the object to which they refer -- which in C++ is an intrinsic
property of the object]

>
>I have the distinct feeling that it should read "....a class that has NOT
>a (VIRTUAL) destructor and its static type....". Otherwise the statement
>makes no sense to me.

 If you say:

 Derived *d = new Derived[20];

then you can say

 delete []d;

but given

 Base *b = d;

then

 delete []b;

is not allowed. Simple. Arrays aren't 'polymorphic'.



--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

Hi,

Can anyone tell me whether the following paragraph exerted from the
ANSI draft standards of 25 Jan 94 makes sense?

"In the second alternative, i.e.
        delete[] Objects;
if the dynamic type of the object to be deleted is a class that has a
destructor and its static type is different from its dynamic type, the
result is undefined."

I have the distinct feeling that it should read "....a class that has NOT
a (VIRTUAL) destructor and its static type....". Otherwise the statement
makes no sense to me. However, apparently compiler vendors have read the
draft document literally and implemented it to the letter.
Consider the following code example:

class Base {
public:
           Base()
           {  _bvalue= new int[10];
              cout << "Base::Base()" << end;
           }
   virtual ~Base()
           {    delete[] _bvalue;
                cout << "Base::~Base()" << endl;
           }
private:
   int*         _bvalue;
};


class Derived : public Base {
public:
           Derived()
           {  _dvalue= new int[10];
              cout << "Derived::Derived()" << endl;
           }
 virtual   ~Derived()
           {    delete[] _dvalue;
              cout << "Derived::~Derived()" << endl;
           }
private:
   int*         _dvalue;
};

int main(int argc, char* argv[])
{
        Base*   bp1 = new Derived;
        Base*   bp2 = new Derived[2];

        delete  bp1;    // calls Derived::~Derived()
                        // as expected.
        delete[] bp2;   // calls only Base::~Base(),
                        // and not Derived destructors!
                        // --> MEMORY LEAK !!!
}

This code is likely to appear in a similar form when one is using
arrays of specialised Strings, e.g. KeyStrings, and provides a virtual
interface that takes a String* argument.

This code was tested on the Borland C++ 4.0 and IBM C++ compilers, which
showed the same behavior. The GNU g++ compiler core dumped on the delete[]
instruction in the last line. The cfront based compilers on the SGI and the
SUN work well (hooray!). But they are somewhat older than the generic
compilers mentioned above.

Is this really the way we define the delete[] behavior? What if the class
has no destructor defined at all? What about the behavior in that case?

In order to make it work currently, we have to implement arrays of objects
using a generic Array object. However, this causes an unacceptable overhead
in time critical applications. Please give me your comments on this.

I really need any help I can get !!!! How do you guys solve this problem?

Regards,

Richard Centeno
Rijksuniversiteit Leiden
rcenteno@iris.biophys.LeidenUniv.nl
or centenoneelenr@ksepl.nl