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. Reference stability in QVector/QList
Forum Updated to NodeBB v4.3 + New Features

Reference stability in QVector/QList

Scheduled Pinned Locked Moved Solved General and Desktop
18 Posts 6 Posters 1.5k Views 3 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.
  • JonBJ JonB

    [EDIT: Forked from https://forum.qt.io/topic/121963/random-crash-with-qvector/ --JKSH]

    Purely OOI, if the OP changed to QList<int> data, does Qt implementation guarantee that int* p = &data[0]; stays pointing to that the data which was stored there (I realize it may no longer be the 0th element over time if inserts, but it will still be in the list), unlike for a QVector whose data may get moved?

    kshegunovK Offline
    kshegunovK Offline
    kshegunov
    Moderators
    wrote on last edited by
    #8

    @JonB said in Random crash with QVector:

    Purely OOI, if the OP changed to QList<int> data, does Qt implementation guarantee that int* p = &data[0]; stays pointing to that the data which was stored there (I realize it may no longer be the 0th element over time if inserts, but it will still be in the list), unlike for a QVector whose data may get moved?

    Not for int and Qt6, in Qt5 for types where sizeof(T) > sizeof(void *) you get reference stability, however even then that's not how one exploits it - rather you'd get a pointer/reference to the object itself, and work on that, not a pointer to the list/index w/e.

    Anyway, that's finicky and a bad idea to begin with. If one wants to enforce the reference stability you either go with a linked list std::list, or simply store an array of pointers in the QVector/QList, then you're explicit and reordering of the pointers doesn't change the object's addresses themselves.

    Read and abide by the Qt Code of Conduct

    1 Reply Last reply
    3
    • Christian EhrlicherC Christian Ehrlicher

      @JonB said in Random crash with QVector:

      that's why I use a list

      QList is no std::list (And I still don't understand why now QVector was killed in favor of QList in Qt6... but that's another topic)

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

      @Christian-Ehrlicher said in Random crash with QVector:

      QList is no std::list

      Precisely! Hence expectations may differ.

      (And I still don't understand why now QVector was killed in favor of QList in Qt6

      Nor I. Except that if QList<> is contiguous one can see how close they may be.

      1 Reply Last reply
      0
      • Christian EhrlicherC Christian Ehrlicher

        @JonB said in Random crash with QVector:

        that's why I use a list

        QList is no std::list (And I still don't understand why now QVector was killed in favor of QList in Qt6... but that's another topic)

        kshegunovK Offline
        kshegunovK Offline
        kshegunov
        Moderators
        wrote on last edited by
        #10

        @Christian-Ehrlicher said in Random crash with QVector:

        And I still don't understand why now QVector was killed in favor of QList in Qt6... but that's another topic

        I liked QList and having the two minor optimizations it provided, but to leverage that one needs to be educated. I suppose no one wanted to spread the knowledge enough, so it got axed instead.

        Read and abide by the Qt Code of Conduct

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

          @kshegunov said in Random crash with QVector:

          so it got axed instead.

          That's the problem - it's not. A well defined QVector was replaced with a QList which creates a lot of confusions with std::list - this was just stupid and will create a lot of questions in the near future here.

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

          1 Reply Last reply
          3
          • J.HilkJ J.Hilk

            @JonB QList is very complicated, and I#m not fully in the topic, but in essence it has 2 modi either as a continuous array like a vector or as indeed the normal list implementation

            But is only holds true in Qt5 and earlier. in Qt6 QList and QVector are the same, and IIRC it's now always guaranteed to be a continuous memory chunk.

            I may be wrong here, I didn't follow the whole topic on QVecter Vs QList

            coffeesmokeC Offline
            coffeesmokeC Offline
            coffeesmoke
            wrote on last edited by coffeesmoke
            #12

            @J-Hilk Hi.
            With the development of c++ and the inclusion of STL in the standard, I think the use of classes like QVector is left for compatibility. When developing, I use std::vector. To interact within the Qt Framework, I use QVector<T> QVector::fromStdVector(const std::vector<T> &vector).
            This approach makes it possible to drill down classes into inheritors of QObject with Q_OBJECT macros (b tail of moc_* files) and c++ classes of standard 11 and higher with STL containers.

            J.HilkJ JonBJ JKSHJ 3 Replies Last reply
            0
            • coffeesmokeC coffeesmoke

              @J-Hilk Hi.
              With the development of c++ and the inclusion of STL in the standard, I think the use of classes like QVector is left for compatibility. When developing, I use std::vector. To interact within the Qt Framework, I use QVector<T> QVector::fromStdVector(const std::vector<T> &vector).
              This approach makes it possible to drill down classes into inheritors of QObject with Q_OBJECT macros (b tail of moc_* files) and c++ classes of standard 11 and higher with STL containers.

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

              @coffeesmoke I'm not a fan of snake_case, so I try to stay away from the standard, if I can 😉


              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
              2
              • coffeesmokeC coffeesmoke

                @J-Hilk Hi.
                With the development of c++ and the inclusion of STL in the standard, I think the use of classes like QVector is left for compatibility. When developing, I use std::vector. To interact within the Qt Framework, I use QVector<T> QVector::fromStdVector(const std::vector<T> &vector).
                This approach makes it possible to drill down classes into inheritors of QObject with Q_OBJECT macros (b tail of moc_* files) and c++ classes of standard 11 and higher with STL containers.

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

                @coffeesmoke said in Reference stability in QVector/QList:

                QVector::fromStdVector

                Doesn't this (and for that matter toStdVector() too) do a copy?

                Separately, I note in https://doc.qt.io/qt-5/qvector.html#fromStdVector (for toVector() too)

                Note: Since Qt 5.14, range constructors are available for Qt's generic container classes and should be used in place of this method.

                coffeesmokeC 1 Reply Last reply
                0
                • JonBJ JonB

                  @coffeesmoke said in Reference stability in QVector/QList:

                  QVector::fromStdVector

                  Doesn't this (and for that matter toStdVector() too) do a copy?

                  Separately, I note in https://doc.qt.io/qt-5/qvector.html#fromStdVector (for toVector() too)

                  Note: Since Qt 5.14, range constructors are available for Qt's generic container classes and should be used in place of this method.

                  coffeesmokeC Offline
                  coffeesmokeC Offline
                  coffeesmoke
                  wrote on last edited by
                  #15

                  @JonB yes, this is a copying method. i rarely use this, for example, to pass a copy of data to UI-classes.
                  All business logic is implemented on STL often in private sections of code. Perhaps working with the QVector class ... maybe you won't need it: stl is enough::vector.

                  Here you need to look at the task and choose. I apologize for the long speech. :)

                  1 Reply Last reply
                  0
                  • coffeesmokeC coffeesmoke

                    @J-Hilk Hi.
                    With the development of c++ and the inclusion of STL in the standard, I think the use of classes like QVector is left for compatibility. When developing, I use std::vector. To interact within the Qt Framework, I use QVector<T> QVector::fromStdVector(const std::vector<T> &vector).
                    This approach makes it possible to drill down classes into inheritors of QObject with Q_OBJECT macros (b tail of moc_* files) and c++ classes of standard 11 and higher with STL containers.

                    JKSHJ Online
                    JKSHJ Online
                    JKSH
                    Moderators
                    wrote on last edited by
                    #16

                    @J-Hilk said in Reference stability in QVector/QList:

                    in Qt6 QList and QVector are the same, and IIRC it's now always guaranteed to be a continuous memory chunk.

                    That's correct. In Qt 6, QList and QVector are different names for the same class, and that class is the Qt version of std::vector.

                    @coffeesmoke said in Reference stability in QVector/QList:

                    With the development of c++ and the inclusion of STL in the standard, I think the use of classes like QVector is left for compatibility.

                    Note: Copying QVector is cheap but copying std::vector is expensive, because Qt containers are implicitly shared (copy-on-write) but STL containers are not.

                    Also, although std::vector is quite similar to QVector, std::string is woefully inadequate compared to QString.

                    Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                    coffeesmokeC kshegunovK 2 Replies Last reply
                    4
                    • JKSHJ JKSH

                      @J-Hilk said in Reference stability in QVector/QList:

                      in Qt6 QList and QVector are the same, and IIRC it's now always guaranteed to be a continuous memory chunk.

                      That's correct. In Qt 6, QList and QVector are different names for the same class, and that class is the Qt version of std::vector.

                      @coffeesmoke said in Reference stability in QVector/QList:

                      With the development of c++ and the inclusion of STL in the standard, I think the use of classes like QVector is left for compatibility.

                      Note: Copying QVector is cheap but copying std::vector is expensive, because Qt containers are implicitly shared (copy-on-write) but STL containers are not.

                      Also, although std::vector is quite similar to QVector, std::string is woefully inadequate compared to QString.

                      coffeesmokeC Offline
                      coffeesmokeC Offline
                      coffeesmoke
                      wrote on last edited by
                      #17

                      @JKSH Yes. :)

                      1 Reply Last reply
                      0
                      • JKSHJ JKSH

                        @J-Hilk said in Reference stability in QVector/QList:

                        in Qt6 QList and QVector are the same, and IIRC it's now always guaranteed to be a continuous memory chunk.

                        That's correct. In Qt 6, QList and QVector are different names for the same class, and that class is the Qt version of std::vector.

                        @coffeesmoke said in Reference stability in QVector/QList:

                        With the development of c++ and the inclusion of STL in the standard, I think the use of classes like QVector is left for compatibility.

                        Note: Copying QVector is cheap but copying std::vector is expensive, because Qt containers are implicitly shared (copy-on-write) but STL containers are not.

                        Also, although std::vector is quite similar to QVector, std::string is woefully inadequate compared to QString.

                        kshegunovK Offline
                        kshegunovK Offline
                        kshegunov
                        Moderators
                        wrote on last edited by
                        #18

                        @JKSH said in Reference stability in QVector/QList:

                        Note: Copying QVector is cheap but copying std::vector is expensive, because Qt containers are implicitly shared (copy-on-write) but STL containers are not.

                        Which is a rather important point if you're passing them around through signals/slots ...

                        Read and abide by the Qt Code of Conduct

                        1 Reply Last reply
                        4

                        • Login

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