Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Update: Forum Guidelines & Code of Conduct

    Solved Exception in deleting an array

    General and Desktop
    exception
    4
    15
    3191
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      ddze last edited by

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

      1 Reply Last reply Reply Quote 0
      • X
        XavierLL last edited by 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

        D 1 Reply Last reply Reply Quote 2
        • D
          ddze @XavierLL last edited by

          @XavierLL ,

          thank you so much.

          1 Reply Last reply Reply Quote 0
          • X
            XavierLL last edited by

            You're welcome :)

            1 Reply Last reply Reply Quote 0
            • andr
              andr last edited by

              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.

              D 1 Reply Last reply Reply Quote 0
              • D
                ddze @andr last edited by

                @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 1 Reply Last reply Reply Quote 0
                • kshegunov
                  kshegunov Moderators @ddze last edited by 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.

                  Read and abide by the Qt Code of Conduct

                  D 1 Reply Last reply Reply Quote 0
                  • D
                    ddze @kshegunov last edited by 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 1 Reply Last reply Reply Quote 0
                    • kshegunov
                      kshegunov Moderators @ddze last edited by 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.

                      Read and abide by the Qt Code of Conduct

                      D 1 Reply Last reply Reply Quote 0
                      • D
                        ddze @kshegunov last edited by

                        @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 1 Reply Last reply Reply Quote 0
                        • kshegunov
                          kshegunov Moderators @ddze last edited by

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

                          Read and abide by the Qt Code of Conduct

                          D 2 Replies Last reply Reply Quote 1
                          • D
                            ddze @kshegunov last edited by

                            @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 1 Reply Last reply Reply Quote 0
                            • D
                              ddze @kshegunov last edited by 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.

                              1 Reply Last reply Reply Quote 0
                              • kshegunov
                                kshegunov Moderators @ddze last edited by 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.

                                Read and abide by the Qt Code of Conduct

                                D 1 Reply Last reply Reply Quote 1
                                • D
                                  ddze @kshegunov last edited by

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

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post