a weird problem

**Antigloss** · 06-21-2010

hi guys and gals, here i've got a problem and ask for your kindly help.

Code:

#include <cstdlib>
#include <cmath>
#include <iosfwd>
#include <iostream>
#include <iterator>
#include <vector>
#include <cstring>
#include <iostream>
#include <stdexcept>
#include <string>
#include <sstream>
using namespace std;

class t1 {
public:
    t1() { cout << "t1: " << this << endl; }
    virtual ~t1() { cout << "~t1: " << this << endl; }
    int a, b, c;
    char d, f, g;
};

class t2 : public t1 {
public:
    t2() { cout << "t2: " << this << endl; }
    ~t2() { cout << "~t2: " << this << endl; }
    int i1, i2, i3;
};

int main()
{
    t1* p11 = new t1;
    delete p11;  // OK

    t1* p12 = new t1[2];
    delete [] p12;  // OK

    t2* p21 = new t2[2];
    delete [] p21;  // OK

    t1* p22 = new t2;
    delete p22;  // OK

    t1* p23 = new t2[2];
    delete [] p23;  // Core Dump, why?
}

why can't we delete an array of type t2 by deleting a 'pointer of type t1(p23)' that is actually pointing to 'new t2[2]', whereas we do can delete an object of type t2 by deleting a 'pointer of type t1(p22)'

**CornedBee** · 06-21-2010

Forget deleting. You should simply never have a pointer to base pointing to an array of derived. Pointer arithmetic is messed up for that.

You can have a pointer to base to individual elements of an array of derived. This is not a syntactic difference (C++ doesn't have a separate notion of 'this pointer points at the start of an array'), but an important consideration nonetheless. Of course, since the pointer isn't considered to point at the array, you can't delete the array through it.

As for delete itself, the C++ standard has the following to say in [expr.delete]p3:

In the second alternative (delete array), if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined.

In other words, deleting an array through a pointer to base is a bad idea.
The concrete reason for this is
a) that there is no use case for this, since as I explained above, having such a pointer in the first place is bad, and
b) that it simplifies implementation for compiler writers if they don't have to consider this case.

**grumpy** · 06-21-2010

Originally Posted by CornedBee

b) that it simplifies implementation for compiler writers if they don't have to consider this case.

In Antigloss's code, the compiler could detect the difference.

The problems come in if the creation and deletion happen in functions within separate compilation units - the compiler would have no way of detecting the mismatch (short of changing compilation model to something other than separate compilation of source files). The whole point of the separate compilation model is that behaviour of a program won't vary if a function is moved between source files.

**CornedBee** · 06-21-2010

In Antigloss's code, the compiler could detect the difference.

Difference between what?
A static analyzer could easily detect the UB here, but it would require actual flow analysis, which gets very hard very quickly in more complex examples.

**grumpy** · 06-22-2010

Originally Posted by CornedBee

Difference between what?

Difference between defined and undefined behaviours, or (if you prefer) the difference between the cases within the example.

Thread: a weird problem

Thread Tools

Search Thread

Display

a weird problem

Similar Threads

Weird Problem With Pointer

Weird problem on '02 3.4L V6 auto

Really Weird itoa Problem

a weird problem with my code on writing & reading from file

Weird class problem!