Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QVector one-line deep copy?
Forum Updated to NodeBB v4.3 + New Features

QVector one-line deep copy?

Scheduled Pinned Locked Moved Solved General and Desktop
18 Posts 4 Posters 4.9k Views 4 Watching
  • 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.
  • Christian EhrlicherC Offline
    Christian EhrlicherC Offline
    Christian Ehrlicher
    Lifetime Qt Champion
    wrote on last edited by Christian Ehrlicher
    #9

    @JonB said in QVector one-line deep copy?:

    for (MyStruct &cur : current)

    This will also force a detach.

    /edit:

    int main(int argc, char **argv)
    {
      QVector<s> myVec = {{1, 2}, {3 ,4}};
      QVector<s> copy(myVec);
      
      for (auto &v : myVec)
        v.one = 42;
      qDebug() << myVec[0].one << myVec[1].one;
      qDebug() << copy[0].one << copy[1].one;;
    }
    

    -->
    42 42
    1 3

    Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
    Visit the Qt Academy at https://academy.qt.io/catalog

    JonBJ 1 Reply Last reply
    3
    • Christian EhrlicherC Christian Ehrlicher

      @JonB said in QVector one-line deep copy?:

      for (MyStruct &cur : current)

      This will also force a detach.

      /edit:

      int main(int argc, char **argv)
      {
        QVector<s> myVec = {{1, 2}, {3 ,4}};
        QVector<s> copy(myVec);
        
        for (auto &v : myVec)
          v.one = 42;
        qDebug() << myVec[0].one << myVec[1].one;
        qDebug() << copy[0].one << copy[1].one;;
      }
      

      -->
      42 42
      1 3

      JonBJ Offline
      JonBJ Offline
      JonB
      wrote on last edited by JonB
      #10

      @Christian-Ehrlicher
      Sigh :) OK, I'll have to produce a repro... Because code works with saved.append() but not with saved = current.

      Hang on, one more. Same to you as to @J-Hilk previously. I can't use QVector<int> copy(myVec);. Copying is not done during constructor. current & saved are persistent member variables. It is called explicitly at various points. So it has to be something like saved = current. Does that make a difference to what you are telling me should work?

      Christian EhrlicherC J.HilkJ 2 Replies Last reply
      0
      • JonBJ JonB

        @Christian-Ehrlicher
        Sigh :) OK, I'll have to produce a repro... Because code works with saved.append() but not with saved = current.

        Hang on, one more. Same to you as to @J-Hilk previously. I can't use QVector<int> copy(myVec);. Copying is not done during constructor. current & saved are persistent member variables. It is called explicitly at various points. So it has to be something like saved = current. Does that make a difference to what you are telling me should work?

        Christian EhrlicherC Offline
        Christian EhrlicherC Offline
        Christian Ehrlicher
        Lifetime Qt Champion
        wrote on last edited by
        #11

        @JonB said in QVector one-line deep copy?:

        Does that make a difference to what you are telling me should work?

        No, it does exactly the same, our version calls the copy operator, yours the operator=() but they do the same (if not it would be wrong by design ;) ). Just check it out with my little repro - it does not change anything.

        Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
        Visit the Qt Academy at https://academy.qt.io/catalog

        JonBJ 2 Replies Last reply
        0
        • Christian EhrlicherC Christian Ehrlicher

          @JonB said in QVector one-line deep copy?:

          Does that make a difference to what you are telling me should work?

          No, it does exactly the same, our version calls the copy operator, yours the operator=() but they do the same (if not it would be wrong by design ;) ). Just check it out with my little repro - it does not change anything.

          JonBJ Offline
          JonBJ Offline
          JonB
          wrote on last edited by JonB
          #12

          @Christian-Ehrlicher
          Hmm, now just wait a cotton-picking moment! @sierdzio appears to sort me out, after all!

          QVector<MyStruct> current, saved;
          
          // on its own, this does *not* work;
          // when I alter something in `current` it gets changed in `saved`
          saved = current; 
          // as soon as I put this line next, it *does* work, I see changes when I later alter something in `current`
          saved.detach();
          

          So..... ?

          1 Reply Last reply
          0
          • JonBJ JonB

            @Christian-Ehrlicher
            Sigh :) OK, I'll have to produce a repro... Because code works with saved.append() but not with saved = current.

            Hang on, one more. Same to you as to @J-Hilk previously. I can't use QVector<int> copy(myVec);. Copying is not done during constructor. current & saved are persistent member variables. It is called explicitly at various points. So it has to be something like saved = current. Does that make a difference to what you are telling me should work?

            J.HilkJ Offline
            J.HilkJ Offline
            J.Hilk
            Moderators
            wrote on last edited by
            #13

            @JonB
            obviously the const only works on construction 😉

            that said a small test example:

            struct MyStruct {
                int memberA;
                QString memberC;
                MyStruct() : memberA{0}, memberC{QLatin1String()}
                {}
            };
            
            #include <QDebug>
            #include <vector>
            int main (int argc, char *argv[])
            {
                QVector<MyStruct> current{1};
                QVector<MyStruct> saved(current);
                std::vector<MyStruct> deepCopy;
                for(auto s : current)
                    deepCopy.push_back(s);
                current.first().memberA = 10;
            
                qDebug() << current.first().memberA << saved.first().memberA << deepCopy.at(0).memberA;
            }
            

            results in
            10 0 0

            so it detaches automatically.

            It doesn't for you?


            Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


            Q: What's that?
            A: It's blue light.
            Q: What does it do?
            A: It turns blue.

            1 Reply Last reply
            3
            • Christian EhrlicherC Christian Ehrlicher

              @JonB said in QVector one-line deep copy?:

              Does that make a difference to what you are telling me should work?

              No, it does exactly the same, our version calls the copy operator, yours the operator=() but they do the same (if not it would be wrong by design ;) ). Just check it out with my little repro - it does not change anything.

              JonBJ Offline
              JonBJ Offline
              JonB
              wrote on last edited by JonB
              #14

              @Christian-Ehrlicher , or @jsulm [or indeed any of you helpful experts, it's just that this is getting tricky...]
              I wonder if you would care to help. Because I think we need your deep understanding of C++ to see if you can understand what is going on!

              As I said, in my code it definitely does not work without an explicit detach(), and (I think) it will be to do with pointers.

              Just to resume: if I break just prior to the assignment into the struct of an element in current I can see that element in both current & saved, and they are indeed showing the same address. After the assignment the address remains the same in both of them, hence my observed behaviour. There is no detachment!

              If in the debugger I put a watch point on the element in question. I do that via current[13] & saved[13] (debugger won't allow .at(13)). If I do that, at that instant the addresses change --- i.e. detachment occurs, because of the []. (I think it is the current[13] which changes while saved[13] stays the same, if that's what you would expect.)

              Like you, I don't think I saw that in a test program. However, my real code has a nasty wrinkle going on. And I'm wondering if it's all @jsulm's fault!

              In https://forum.qt.io/topic/120395/return-pointer-to-member-in-const-method/8 he proposed the following code (you'd have to read the whole thread to understand why), which I now use:

              const int *pointerToMember() const { return &member; }
              
              int *pointerToMember()  { const MyClass *_this = this;  return const_cast<int*>(_this->pointerToMember()); } // Now compiler knows that you want to call const pointerToMember
              

              In my code for the first overload, I am actually marching through the QVector current returning a reference to the found element as a pointer, or nullptr if not found.

              The way I get the pointer to the element I need to change (in current) is via the second, "writeable" overload there.

              Now then: I have a suspicion this is the cause? I am getting a writeable element in a (shared) QVector via a const_cast<> of a const method. Does this cheat by any chance disable/break the "detach-on-write" we are relying on to make sure element in current gets changed but not in saved. I have a feeling.... :)

              1 Reply Last reply
              1
              • Christian EhrlicherC Offline
                Christian EhrlicherC Offline
                Christian Ehrlicher
                Lifetime Qt Champion
                wrote on last edited by
                #15

                At least this could be a reason although I don't see your actual code to say it for sure.
                I would have returned &member directly also in the non-const version - then this should not happen for sure.

                Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
                Visit the Qt Academy at https://academy.qt.io/catalog

                JonBJ 1 Reply Last reply
                3
                • Christian EhrlicherC Christian Ehrlicher

                  At least this could be a reason although I don't see your actual code to say it for sure.
                  I would have returned &member directly also in the non-const version - then this should not happen for sure.

                  JonBJ Offline
                  JonBJ Offline
                  JonB
                  wrote on last edited by JonB
                  #16

                  @Christian-Ehrlicher
                  :) OK, here's the lookup code:

                  const Class::MyStruct *Class::find(int arg) const
                  {
                      for (const MyStruct &ms : current)
                          if (ms.arg== arg)
                              return &ms;
                      return nullptr;
                  }
                  
                  Class::MyStruct *Class::find(int arg)
                  {
                      const Class *_this = this;
                      return const_cast<MyStruct *>(_this->find(arg));
                  }
                  
                  QVector<MyStruct> current, saved;  // member variables
                  current.append(...);  // this can be called at various times
                  saved = current;  // this can be called at various times
                  
                  MyStruct *ms = find(something);  // this will be found in current
                  if (ms != nullptr)
                      ms->someMember = newValue;  // want to change in current, only
                  

                  On that last line the element in current gets its content changed, but the element in saved continues to point to the same, now changed, element, with no "detachment".

                  It's difficult at present for me to break this up, as code presently relies elsewhere on these two definitions.

                  I am suggesting that the const_cast<> in the second overload is what "breaks" any detachment, is that possible? I'm thinking that it leads to the code/Qt thinking that no detachment is necessary for an element, because it thinks that must have already happened given the non-const return result, something like that?

                  If so, how would you like me to rewrite it? Bear in mind the whole of the referenced thread, in which I steadfastly refuse to return an index from my lookup find(), as that is so inefficient compared to a pointer :)

                  Finally, assuming it is @jsulm's solution to that thread which causes the problem, can I sue him? :-:

                  1 Reply Last reply
                  1
                  • Christian EhrlicherC Offline
                    Christian EhrlicherC Offline
                    Christian Ehrlicher
                    Lifetime Qt Champion
                    wrote on last edited by
                    #17

                    Correct - this code kills the copy on write behavior since current is not detached in find() because it's a const operation there.

                    Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
                    Visit the Qt Academy at https://academy.qt.io/catalog

                    JonBJ 1 Reply Last reply
                    4
                    • Christian EhrlicherC Christian Ehrlicher

                      Correct - this code kills the copy on write behavior since current is not detached in find() because it's a const operation there.

                      JonBJ Offline
                      JonBJ Offline
                      JonB
                      wrote on last edited by
                      #18

                      @Christian-Ehrlicher
                      And? :) That solves the mystery here (I can use @sierdzio's explicit detach() for now), but leaves me with the other thread still not correctly answered, now :( You didn't say if I could sue @jsulm there....

                      Thanks to you, and all, for answering. I didn't even recall when I raised this "deep copy" question that it was going via/could be related to the const_cast<> method.

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved