Exception in deleting an array



  • Hi, I have a strange exception that happens during the delete of an object.

    declaration

    class Something{
    public
    QList<QList<SomeItem *> > *getObject() const;
    private:
    QList<QList<SomeItem *>> *object;
    };
    

    definition

    // constructor
    Something::Something(){
    QList<QList<SomeItem *>> *object = 0;
    }
    // destructor
    Something::~Something(){
        if(object!=0){
            qDebug()<<"deleting objects";
            object->clear();
            delete object; object=0;  // Exception (SEH)
        }
    }
    

    I do not understand why the condition (object!= 0) is passed as a true? ( no other initialization aside from the origina where object is assigned 0. )



  • 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



  • @XavierLL ,

    thank you so much.



  • You're welcome :)



  • 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.



  • @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.


  • Qt Champions 2016

    @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.



  • @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
    

  • Qt Champions 2016

    @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.



  • @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).


  • Qt Champions 2016

    @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).



  • @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.



  • @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.


  • Qt Champions 2016

    @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.



  • @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.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.