Exception in deleting an array

[XavierLL]

Hi,

You are redeclaring object in the constructor. The constructor should be:

Something::Something(){
 object = 0;
}

without the type, is a typical error ;)

Hope it helps

[ddze]

@XavierLL ,

thank you so much.

[XavierLL]

You're welcome :)

[andr]

Note that you shouldn't have a QList<...> pointer member to start with. Just use the object directly as member. This also removes the need for the code you put in the constructor and destructor.

[ddze]

@andr

I must definitly disagree with you. Your suggestion depends on the nature of using it, how we use the object. The reassignment of the entire QList container to another QList invites a copy construction. By using a QList pointer I can just reassign it to an existing QList object somwhere else without copying it.

[kshegunov]

@ddze
You may disagree because you probably haven't read how QList manages its data. It uses implicit sharing, so the copy constructor reassigns a pointer and doesn't copy the data. The data is detached when a non-const method is invoked and only if more than one object references that data. So for all intents and purposes passing QList * around is pretty much pointless.

[ddze]

@kshegunov ,

good , now tell me this situation

QVector<QString*> vecItems1;    // ref count = 1
QVector<QString*> vecItems2;    //  ref count =1

for(int c=5;c<20;++c){
QString s = QString::number(c);
        vecItems.1.append(s);
}
vecItems2 = vecitems1;  // not copy constructor - both implicitly share same memory (refCount ==2) , 

// here we come to call to copy constructor
for(int c=0;c<5;++c){
QString s = QString::number(c);
        vecItems.2.append(s);
}
 // vecItems1 -> changes its  refCount =1
//  vecItems2  ,called copy constructor refCount =1

[kshegunov]

@ddze
What do you want to know? Yes, it causes copying to occur (on the first call to vecItems2.append(s)). But let me ask you, can you prevent data copying by using QVector<QString*> * so when that function finishes you have number 1-20 in vecItems1 and 5 more in vecItems2? I would think not ...

PS.
Btw, the same considerations apply for QString and QString *, as well as any other implicitly shared class.

[ddze]

@kshegunov said:

can you prevent data copying by using QVector<QString*> *

Of course that I can , by a simple dereferencing the pointer to different data structure.
I am surprised you do not know that.

P.S
By the way, yes you really helped me twice so I have a respect towards you, but stick to the subject without portraiting anyone (your claim I haven't read ... bla bla bla).

[kshegunov]

@ddze

Of course that I can , by a simple dereferencing the pointer to different data structure.

Maybe I'm missing something, but perhaps you could explain what you mean by that?

but stick to the subject without portraiting anyone

It was not my intent, I'm sorry it was perceived like this. I just meant that many people (happens quite often in the forum) are unaware that Qt uses that technique (STL doesn't).

[ddze]

@kshegunov

"Of course that I can , by a simple dereferencing the pointer to different data structure."

Maybe I'm missing something, but perhaps you could explain what you mean by that?

here we go ...

QVector<QString*> *pVec=0;
QVector<QString*> *pVec2= new QVector<QString*>;
QVector<QString*> *pVec3= new QVector<QString*>;
QVector<QString*> *pVec_nn= new QVector<QString*>;

pVec = pVec2; // no copy constructor
pVec = pVec2; // dereferencing , no copy constructor
pVec = pVec3; // dereferencing , no copy constructor
pVec = pVec_nn; // dereferencing , no copy constructor

I hope it clarifies what I meant.

[ddze]

@kshegunov ,

now I see why you replied.

I had written "The reassignment of the entire QList container to another QList invites a copy construction." Clearly the flaw in my explanation.

Not the reassignment, but the changing of the content in one of variables that implicitly share the data with others calls for a copy constructor.

[kshegunov]

@ddze

I hope it clarifies what I meant.

It does, but the last snippet is still very different from the one before that.

In the first one you do this:

QVector<QString*> vecItems2 = vecitems1;  // not copy constructor - both implicitly share same memory (refCount ==2)

while in the second one you do this (pointers were converted to references for clarity):

QVector<QString*> & vecItems2 = vecitems1;

See the difference? That's what I meant that in your first example no matter whether or not you use pointers you still are going to end up copying data. So your first example can be adapted in the described way and it won't call copying of data. So to be completely clear:

QVector<QString*> pVec2;
QVector<QString*> pVec3;
QVector<QString*> pVec_nn;

QVector<QString*> & pVec = pVec2; // not causing copying (ever!)
pVec = pVec2; // not causing copying 
pVec = pVec3; // not causing copying
pVec = pVec_nn; // not causing copying

Not the reassignment, but the changing of the content in one of variables that implicitly share the data with others calls for a copy constructor.

I do agree, but see above explanation.

Kind regards.

[ddze]

@kshegunov ,

agree with what you have written.

I think , I was in rush to reply to the one who objected on using the pointer to a container structure.

So I went on and hoping to convey the idea of me doing it rather than being careful in writing the correct way.

All the best to you Kshegunov.